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Vorwort 



Umfangreicher Einsatz unseres Buches in der Lehre an verschiedenen Stand- 
orten hatte bereits vor längerer Zeit eine Neuauflage notwendig gemacht. 
Aufgrund verschiedener Einflussfaktoren wurde dieses Projekt jedoch immer 
wieder verschoben. Umso mehr freuen wir uns, nunmehr die 2. Auflage unse- 
rer „Grundlagen der Wirtschaftsinformatik“ vorlegen zu können. Als wesent- 
licher Einflussfaktor sei aus persönlicher Sicht darauf hingewiesen, dass wir 
Weitsicht bei der Auswahl des Titelbildes für die 1. Auflage bewiesen hatten, 
indem wir in der Zeit zwischen den beiden Auflagen unseren Arbeitsplatz von 
der Technischen Universität Braunschweig nach Hamburg (dem Standort des 
abgebildeten Containerterminals) verlegt haben. 

Aufgrund der positiven Aufnahme unseres Buches bei Studierenden wie 
bei Kollegen haben wir die Grundkonzeption beibehalten. Im Wesentlichen 
bedeutet dies auch, dass wir uns nicht nur mit Grundlagen „der“ Wirtschafts- 
informatik befassen, sondern auch Grundlagen „für die“ Wirtschaftsinforma- 
tik behandeln. In diesem Sinne sind selbst in einer schnelllebigen Disziplin 
wie der Wirtschaftsinformatik viele Inhalte im Grundlagenbereich als stabil 
zu betrachten. Auf der anderen Seite sind in diversen Bereichen umfassende 
Veränderungen zu konstatieren, derer man teilweise erst gewahr wird, wenn 
man sich tatsächlich im Rahmen einer Neuauflage explizit darum kümmert. 
In diesem Sinne hoffen wir, einen geeigneten Kompromiss zwischen Neuerun- 
gen und Erweiterungen auf der einen Seite und Konstanz auf der anderen 
Seite gefunden zu haben. 

Für die kritische Durchsicht sei insbesondere Herrn Dr. Frank Schwartz 
sowie Herrn Dr. Kai Brüssau und Herrn Rene Eisenberg gedankt. Herrn Dr. 
Werner Müller vom Springer-Verlag sei insbesondere für seine große Geduld 
sowie die Unterstützung bei einer schnellen Umsetzung in Verbindung mit 
unserem Buch gedankt. 



Hamburg, 
März 2005 



Andreas Fink 
Gabriele Schneidereit 
Stefan Voß 
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Vorwort zur 1. Auflage 



Das Schöne an der Wirtschaftsinformatik, aber auch der Informatik, ist, 
dass sie nicht nur in der Theorie, sondern auch in der Praxis gelebt wird (und 
wir sprechen nicht nur von der Informationsgesellschaft und ihren Folgen). 
Aber auch wir beschreiben sie immer noch in Buchform. Und jeder Autor 
hofft, wie auch wir, dass es zu seinem Themengebiet das Buch gibt. 

„Sind Ihre Augen am Monitor ermüdet? Dann genießen Sie 

das Buchl 

Blendfrei, schneller Bildaufbau, hohe Auflösung, kein Flimmern, 
strahlungsarm, Neigung einstellbar, ergonomisch günstige Handha- 
bung.“ (Büttemeyer (1995), S. 150) 

Die noch relativ junge und dennoch bereits etablierte Disziplin Wirt- 
schaftsinformatik ist eine Schnittstellendisziplin par excellence. Zum einen 
basiert sie auf den Erkenntnissen und Methoden von Informatik und Be- 
triebswirtschaftslehre und versucht insbesondere für letztere Disziplin Lösun- 
gen für Problemstellungen zu entwickeln. Die eigentlichen Grundlagen der 
Wirtschaftsinformatik kommen dabei im Wesentlichen aus der Informatik 
und werden vor allem im Kontext der Modellierung durch eigene Arbeiten 
der Wirtschaftsinformatik erweitert. Zum anderen ist der zentrale Unter- 
suchungsgegenstand der Wirtschaftsinformatik, komplexe Informations- und 
Kommunikationssysteme, typischerweise hochgradig von Schnittstellen (so- 
wohl internen als auch externen, sowohl technischen als auch solchen, die die 
Interaktion zwischen Mensch und Technik betreffen) geprägt. Dieser Sach- 
verhalt ist auf dem Titelbild unseres Buches durch ein ähnlich schnittstel- 
lenintensives reales System symbolisiert: das Containerterminal Burchardkai 
der Hamburger Hafen und Lagerhaus AG, das wir im Buch verschiedentlich 
als Beispiel zur Veranschaulichung ausschnittsweise herangezogen haben. 

Die in diesem Buch behandelten Inhalte orientieren sich an unserer Mei- 
nung nach wesentlichen Themenstellungen der Wirtschaftsinformatik und 
den für deren Verständnis notwendigen Grundlagen bzw. Voraussetzungen. 
Während wir selbstverständlich nicht den Anspruch erheben, die Wirtschafts- 
informatik in ihrer ganzen Breite und Vielfalt darzustellen, haben wir gleich- 
wohl versucht, theoretische und methodische Grundlagen in verschiedenen 
Bereichen zu betrachten (freilich setzt die Gewinnung eines echten Verständ- 
nisses beim Leser zumeist die Vertiefung anhand der angegebenen Literatur 
voraus). Dabei haben wir angestrebt, den Leser bei der Einordnung und dem 
Verstehen von Themen (neben der Angabe von Übungsaufgaben mit Lösungs- 
vorschlägen) durch eine Diskussion relevanter praktischer Problemstellungen 
bzw. realer Anwendungssysteme zu unterstützen. Allerdings wird weitgehend 
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darauf verzichtet, eine einem universitär orientierten Lehrbuch nicht ange- 
messene Aufzählung kurzlebiger bzw. technischer Aspekte zu erörtern bzw. 
einen „Einstieg in den PC- Arbeitsplatz“ bieten zu wollen. 

Die Stoffauswahl dieses Buches lehnt sich an eine gleichnamige Lehrver- 
anstaltung an, die die Autoren seit einigen Jahren für Studierende im Grund- 
studium an der Technischen Universität Braunschweig durchgeführt haben. 
Das Buch richtet sich somit primär an Studierende der Wirtschaftsinformatik 
sowie der Betriebswirtschaftslehre und des Wirtschaftsingenieurwesens. Aber 
auch Praktiker, die einen Überblick über die Grundlagen der Wirtschaftsin- 
formatik erhalten möchten, sollten ihre Freude an der Lektüre haben. 

Das bei einem Lesen des Buches aufkommende Gefühl der großen Brei- 
te und Heterogenität der Grundlagen und Themen der Wirtschaftsinforma- 
tik trügt nicht. Das Bild von dem Wirtschaftsinformatiker als „Sparrings- 
partner“, der beide Seiten, die Informatik wie die Betriebswirtschaftslehre, 
versteht und deren Sprache spricht und als „Mittler zwischen den Welten“ 
fungieren kann, impliziert Entsprechendes. 

Abschließend möchten wir uns bei denen bedanken, die uns bei der Fer- 
tigstellung dieses Buches unterstützt haben. Dies betrifft insbesondere unsere 
Mitarbeiter bzw. Kollegen Kai Gutenschwager, Torsten Heiners, Dirk Reiß 
und Dr. Lutz Sondergeld. Weiterhin danken wir der Hamburger Hafen- und 
Lagerhaus AG für die Erlaubnis der Nutzung des für den Titel verwendeten 
Bildes. Herrn Dr. Werner A. Müller und seinem Team vom Physica- Verlag 
sei für die außerordentlich verständnisvolle und kompetente Begleitung des 
Projektes gedankt. 

Letztendlich hoffen wir, dass wir, wenn vielleicht auch nicht das Buch, so 
doch ein nützliches und für die weitere Beschäftigung mit der Wirtschafts- 
informatik Grundlagen schaffendes und Motivation vermittelndes Buch ge- 
schrieben haben. Kritische Anregungen für Verbesserungen nehmen wir sehr 
gerne entgegen. 



Braunschweig, 
Dezember 2000 



Andreas Fink 
Gabriele Schneidereit 
Stefan Voß 
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1. Einführung 



„Gegenstand der Wirtschaftsinformatik sind , Informations- und 
Kommunikationssysteme in Wirtschaft und Verwaltung‘ (kurz: ,In- 
formationssysteme‘).“ (WKWI (1994), S. 80) 

Informations- und Kommunikationssysteme können als Systeme verstan- 
den werden, die Informationen verarbeiten, d. h. erfassen, übertragen, trans- 
formieren, speichern und bereitstellen. Aus dieser Definition des Untersu- 
chungsgegenstandes kann abgeleitet werden, dass Wirtschaftsinformatik alle 
Aufgaben umfasst, die in Verbindung mit Informations- und Kommunikati- 
onssystemen in Wirtschaft und Verwaltung auftreten. Im Mittelpunkt der 
Wirtschaftsinformatik steht die Unterstützung der Erfüllung betrieblicher 
Aufgaben mittels derartiger Systeme. Ein Hauptziel ist dabei die Integrati- 
on betrieblich relevanter Daten und Prozesse unter Einbeziehung involvierter 
Arbeitsplätze und zunehmend der außerbetrieblichen Umwelt. 

Dieses Begriffsverständnis der Wirtschaftsinformatik hat sich im deut- 
schen Sprachraum weitgehend durchgesetzt und liegt in leicht abgewandelter 
Form auch anderen Lehrbüchern zu Grunde: 

Wirtschaftsinformatik ist die „Wissenschaft, die sich mit der Gestal- 
tung rechnergestützter Informationssysteme in der Wirtschaft be- 
fasst.“ (Hansen und Neumann (2001), S. 22) 

„Die Wirtschaftsinformatik befaßt sich mit der Konzeption, Entwick- 
lung, Einführung, Wartung und Nutzung von Systemen der compu- 
tergestützten Informationsverarbeitung im Betrieb.“ (Mertens et al. 
(2000), S. 1) 

„Wirtschaftsinformatik ist die Wissenschaft von Entwurf, Entwick- 
lung und Einsatz computergestützter betriebswirtschaftlicher Infor- 
mationssysteme.“ (Scheer (1997), S. 1) 

Im angelsächsischen Sprachraum findet sich die Wirtschaftsinformatik ins- 
besondere unter dem Synonym Information Systems wieder, obwohl sich auch 
immer wieder andere Begriffe wie z. B. Business Informatics oder Business 
Computer Science als Übersetzung finden lassen. 

Die interdisziplinäre wissenschaftliche Disziplin Wirtschaftsinformatik ist 
an der Schnittstelle zwischen der Betriebswirtschaftslehre und der (ange- 
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wandten) Informatik, der Wissenschaft von der systematischen und auto- 
matisierten Verarbeitung von Informationen, anzuordnen. Dabei stellt Wirt- 
schaftsinformatik mehr dar als lediglich die Schnittmenge dieser beiden Dis- 
ziplinen, indem im Kontext des Untersuchungsgegenstandes eigene Modelle, 
Methoden und Werkzeuge entwickelt und untersucht werden. 

Innerhalb der Informatik wie auch der Betriebswirtschaftslehre sind di- 
rekt oder indirekt nahezu alle Teilbereiche betroffen, wenn es darum geht, 
Grundlagen der Wirtschaftsinformatik sowie Anwendungsbereiche insbeson- 
dere wirtschaftswissenschaftlicher Art zu beschreiben. So ergeben sich in den 
verschiedenen Funktionsbereichen der Betriebswirtschaftslehre vielfältige An- 
knüpfungspunkte, wie z. B. in der Unternehmensführung und der Organisati- 
on, da durch die Einführung bzw. Nutzung von Informations- und Kommuni- 
kationssystemen in der Regel Veränderungen betrieblicher Abläufe notwendig 
oder erst ermöglicht werden. In diesem Sinne beinhaltet die Wirtschaftsinfor- 
matik auch ein Gutteil an Verantwortung für die Potenzialerkennung neuer 
Informations- und Kommunikationstechnologien für diverse Anwendungsbe- 
reiche in Wirtschaft und Verwaltung. Dass damit bei weitem nicht alle Be- 
ziehungen vollständig erfasst sind, liegt auf der Hand. So sind Bezüge zu 
anderen Fächern wie der Psychologie oder der Mathematik mit der Statistik 
und dem Operations Research (insbesondere an der Schnittstelle zur Betriebs- 
wirtschaftslehre) für die Wirtschaftsinformatik unentbehrlich.^ 

Da Informations- und Kommunikationssysteme in Wirtschaft und Verwal- 
tung (als Gegenstand der Wirtschaftsinformatik) Teil der Realität sind, ist 
die Wirtschaftsinformatik in erster Linie eine Real Wissenschaft. Realwissen- 
schaften zeichnen sich dadurch aus, dass die Untersuchung, Beschreibung und 
Erklärung von Phänomenen der Wirklichkeit im Mittelpunkt der Betrach- 
tung stehen. Ausgehend von der Aufgabe der Gestaltung von Informations- 
und Kommunikationssystemen kann die Wirtschaftsinformatik jedoch auch 
als Ingenieurwissenschaft angesehen werden. Darüber hinaus sind die Ent- 
wicklung und Nutzung formaler Beschreibungsmethoden und Theorien über 
Informations- und Kommunikationssysteme ein zentraler Gegenstand der 
Wirtschaftsinformatik, so dass ebenso eine Einordnung als Formalwissen- 
schaft möglich ist. Im Gegensatz dazu wird in der wissenschaftlichen Literatur 
die Wirtschaftsinformatik zum Teil nur den Realwissenschaften zugeordnet. ^ 



1.1 Informations- und Kommunikationssysteme 

Nach der hier betrachteten Definition der Wirtschaftsinformatik stellen Infor- 
mations- und Kommunikationssysteme (bzw. Informationssysteme) die zen- 
tralen Komponenten der Wirtschaftsinformatik dar. Daher soll in diesem Ab- 
schnitt geklärt werden, was unter diesen Begriffen zu verstehen ist. Daneben 

^ Vgl. hierzu auch die Ausführungen in Mertens (2002). 

^ Für eine weitergehende Erörterung entsprechender Aspekte wird auf den An- 
hang, Abschnitt A.2, verwiesen. 




1.1 Informations- und Kommunikationssysteme 



3 



werden der oftmals in ähnlichem Zusammenhang auftretende Begriff Anwen- 
dungssystem erläutert und einige Beispiele für Informations- und Kommuni- 
kationssysteme vorgestellt. 

Zum besseren Verständnis diskutieren wir zunächst kurz den Begriff Sys- 
tem. Hierunter versteht man im Allgemeinen eine geordnete Gesamtheit von 
zueinander in Beziehung stehenden Elementen. Systeme lassen sich in vieler- 
lei Hinsicht charakterisieren. So wird man Systeme mit einer großen Anzahl 
an Elementen und Beziehungen als komplex bezeichnen. Bestehen interaktive 
Beziehungen eines Systems zu seiner Umwelt, so nennt man es offen und an- 
derenfalls geschlossen. Unterliegt ein System im Zeitablauf Veränderungen, 
so ist es dynamisch, ansonsten ist es statisch. 

Die Wissenschaftliche Kommission Wirtschaftsinformatik im Verband der 
Hochschullehrer für Betriebswirtschaft (WKWI) versteht unter Informations- 
und Kommunikationssystemen (IKS) „soziotechnische Systeme, die mensch- 
liche und maschinelle Komponenten (Teilsysteme) als Aufgabenträger um- 
fassen, die voneinander abhängig sind, ineinander greifen und/oder Zusam- 
menwirken. Im Mittelpunkt steht die Unterstützung bei der Erfüllung be- 
trieblicher Aufgaben. Der Begriffsbestandteil Information verdeutlicht, daß 
es primärer Zweck dieser Systeme ist, die Informationsnachfrage von Aufga- 
benträgern [. . .] zu befriedigen. [. . .] Der Begriffsbestandteil Kommunikation 
verdeutlicht, daß eine Koordination zwischen arbeitsteilig wirkenden Aufga- 
benträgern stattfindet“ (WKWI (1994), S. 80). 

Der Begriff Informationssystem (IS) ist heute im Wesentlichen als Syno- 
nym zu Informations- und Kommunikationssystem zu betrachten, da eine 
Kommunikation (ein Informations- oder Datenaustausch) zwischen Syste- 
men bzw. Systemelementen in der Regel systemimmanent ist. Desgleichen 
sind Kommunikationssysteme ohne die Verwendung von Informationen un- 
denkbar, so dass eine Trennung von Informationssystemen auf der einen und 
Kommunikationssystemen auf der anderen Seite nicht sinnvoll ist. Informa- 
tionssysteme sind zumeist offen, da sie mit ihrer Umwelt interagieren, dy- 
namisch, weil sich Teile des Informationssystems infolge dieser Interaktionen 
verändern können, und komplex, da sie einerseits aus einer großen Anzahl 
an Elementen bestehen und diese andererseits auf vielfältige Art und Weise 
Zusammenhängen . 

Neben dem Begriff Informations- und Kommunikationssystem findet auch 
der Begriff Anwendungssystem in der Literatur zur Wirtschaftsinformatik 
Verwendung. Offensichtlich kann man betriebliche Anwendungssysteme als 
zentrale Komponenten der Wirtschaftsinformatik sehen. Anwendungssyste- 
me beziehen sich (im Gegensatz zu IKS) nur auf eine bestimmte (eng ab- 
gegrenzte) Aufgabe; vgl. u. a. Ferstl und Sinz (2001) sowie Heinrich (2001). 
Ein Anwendungssystem im engeren Sinne ist „die Gesamtheit aller Program- 
me, die als Anwendungssoftware für ein konkretes betriebliches Anwendungs- 
gebiet entwickelt, eingeführt und eingesetzt werden, und [. . .] die zugehöri- 
gen Daten“ (Stahlknecht und Hasenkamp (2005), S. 204). Im weiteren Sinne 
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können unter dem Begriff Anwendungssystem zusätzlich auch die für die 
Nutzung der Anwendungssoftware benötigte Hardware und Systemsoftware 
sowie die erforderlichen Kommunikationseinrichtungen verstanden werden. 
Da Anwendungssysteme nur die Unterstützung eines (eng) begrenzten An- 
wendungsgebietes umfassen, sind sie als Teile von IKS zu verstehen.^ Dies 
gilt insbesondere dann, wenn man von der engeren Definition des Begriffes 
Anwendungssystem ausgeht, da dann IKS zusätzlich z. B. noch Personen und 
Komponenten zur Kommunikation beinhalten; vgl. Ferstl und Sinz (2001). 

IKS lassen sich aus zwei primären Sichtweisen einordnen. Zum einen 
horizontal hinsichtlich des betrachteten Funktionsbereiches sowie zum an- 
deren vertikal bezüglich des Typs der unterstützten Aufgaben; vgl. Abbil- 
dung 1.1. Administrations- und Dispositionssysteme dienen der mengen- oder 
wertmäßigen Abbildung bzw. Abwicklung betrieblicher Abläufe und Situa- 
tionen (typischerweise auf der operativen Ebene). Hierauf aufbauend un- 
terstützen Planungs- und Kontrollsysteme das Management durch entspre- 
chende analytische Funktionalitäten mit der Zielsetzung der Entscheidungs- 
unterstützung. Wichtig ist eine sowohl horizontale als auch vertikale Integra- 
tion der Systeme. 




vertikale 

Integration 



horizontale Integration 

Abb. 1.1. Informationssystempyramide 



Im Folgenden werden beispielhaft einige Aspekte von Informationssys- 
temen im Dienstleistungsbereich diskutiert. Eine ausführlichere Darstellung 
betrieblicher Anwendungssysteme ist in Kapitel 7 dieses Buches zu finden. 
Dienstleistungsunternehmen unterliegen der Besonderheit, dass ihre Produk- 
te im Kern immaterielle Wirtschaftsgüter sind. Beispiele für Dienstleister 
sind Banken und Versicherungen, Beratungsunternehmen, Unternehmen aus 
den Bereichen Handel, Transport, Touristik, Verkehr, Freizeit und Unterhal- 

® Wir verabschieden uns hier für Anwendungssysteme von dem möglicherweise als 
zu eng anzusehenden Begriff der Aufgabe, um Missverständnissen vorzubeugen. 
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tung. Der Absatz entsprechender Produkte erfolgt häufig über einen direkten 
Kundenkontakt. Die Erstellung von Dienstleistungsprodukten unterliegt den 
folgenden vier Phasen: 

• Realisierung der Leistungsbereitschaft durch Kombination interner Pro- 
duktionsfaktoren (z.B. Bereitstellung von Transportmitteln, Hotelbetten), 

• Leistungsvereinbarung mit dem Kunden (z.B. Buchung einer Reise), 

• Leistungserbringung bzw. -durchführung (z.B. Flug zum Reiseziel), 

• Nachbehandlung (z.B. Bearbeitung von Reklamationen). 

Mehr noch als in Industrieunternehmen besitzt der „Produktionsfaktor“ 
Information im Dienstleistungsbereich einen sehr hohen Stellenwert, so dass 
eine Unterstützung der Abläufe durch IKS insbesondere die Beschaffung, 
Verarbeitung, Distribution und Allokation von Informationen sowie die Be- 
arbeitung der Informationsträger (d.h. Dokumente) beinhalten muss. Eine 
Hauptaufgabe von IKS im Dienstleistungsbereich liegt somit in der Steue- 
rung von Informationsflüssen (Informationslogistik). Damit sind für ent- 
sprechende IKS u. a. geeignete Systemschnittstellen notwendig, die eine un- 
ternehmensübergreifend integrierte, informationstechnische Abwicklung von 
Abläufen ermöglichen. 

Zur Verdeutlichung einiger der im Rahmen der integrierten Informations- 
verarbeitung eines Unternehmens auftretenden Aspekte wird im Weiteren 
als Beispiel die Hamburger Hafen und Lagerhaus AG (HHLA) herangezo- 
gen; vgl. http://www.hhla.de. Die HHLA ist das größte Unternehmen der 
See Verkehrs Wirtschaft in Deutschland. Sie betreibt verschiedene Hafenanla- 
gen in Hamburg und ist verantwortlich für die Durchführung des Umschlages 
von jährlich ca. 43 Millionen Tonnen Fracht (insbesondere über so genannte 
Containerterminals) . 

Als Dienstleistungsunternehmen der Verkehrswirtschaft verwendet die 
HHLA diverse Informations- und Kommunikationssysteme mit vielfältigen 
Verflechtungen und Vernetzungen sowohl innerhalb des Unternehmens als 
auch mit Systemen ihrer Kunden. Dies betrifft z. B. Systeme für die Lösung 
komplexer überbetrieblicher Transport- und Distributionsaufgaben, zur La- 
gerverwaltung, zur Verzollung von Gütern sowie diverse Systeme der Planung 
und Steuerung von Containerterminals. 

Mit Hilfe eines IKS lassen sich sämtliche operativen Planungs- und Steue- 
rungsprozesse auf einem Containerterminal vorbereiten und unterstützen. 
Hiervon betroffen sind die Abfertigung sämtlicher Schiffe sowie die LKW- 
und die Bahnabfertigung. Ein wesentlicher Aspekt ist dabei ein effizienter 
Daten- und Informationsaustausch, um z. B. die Avisen von Kunden auf elekt- 
ronischem Wege erhalten und weiter verarbeiten zu können. Daten sind da- 
bei geeignet zu speichern und bereitzuhalten, um sowohl unternehmensweit 
als auch extern über geeignete Schnittstellen (ggf. nach vorheriger Berechti- 
gungsüberprüfung) zur Verfügung zu stehen. 

Geeignete Systeme unterstützen z.B. die Planung sowie die Durchführung 
der Be- und Entladung von Schiffen. So sind für jedes Schiff unter Berück- 
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sichtigung diverser Rahmenbedingungen geeignete Sequenzen festzulegen, in 
welcher Reihenfolge z. B. Container geladen werden, und an die betroffenen 
Bereiche zu übermitteln (u. a. Verladebrücken oder -kräne, Portalhubfahr- 
zeuge für den Transport der Container vom Yard (Lagerbereich auf dem 
Terminal) zu den Brücken und umgekehrt). Basierend auf einem elektroni- 
schen Datenaustausch spielen hier Aspekte wie der Inhalt (hinsichtlich einer 
automatisierten Unterstützung der Verzollung) und das Gewicht einzelner 
Container (hinsichtlich einer „ Weight and RaZance“-Berechnung der Schiffe) 
sowie deren voraussichtlicher Löschhafen (d.h. Entladehafen; insbesondere 
um spätere Umstapelvorgänge zu vermeiden) eine wesentliche Rolle. 

Für Kunden, z. B. Reedereien, mag es von Interesse sein, über das Inter- 
net Containerdaten in Echtzeit abfragen zu können. Darüber hinaus ist ei- 
ne Anbindung an klassische Anwendungssysteme des Finanzwesens und des 
Rechnungswesens zu gewährleisten. 



1.2 Aufgaben der Wirtschaftsinformatik 

„Ziel der Wirtschaftsinformatik ist die Gewinnung von Theorien, Me- 
thoden, Werkzeugen und intersubjektiv nachprüfbaren Erkenntnis- 
sen über/zu IKS in Wirtschaft und Verwaltung und die Ergänzung 
des , Methoden- und Werkzeugkastens‘ der Wissenschaften um sol- 
che der Wirtschaftsinformatik, die den soziotechnischen Erkenntnis- 
und Gestaltungsgegenstand einer wissenschaftlichen Untersuchung 
zugänglich machen.“ (WKWI (1994), S. 81) 

Hauptaufgabe der Wirtschaftsinformatik ist demnach die Erklärung und 
die Gestaltung von Informations- und Kommunikationssystemen in Wirt- 
schaft und Verwaltung. Darüber hinaus kann auch die Beschreibung und 
die Prognose von IKS als Aufgabe der Wirtschaftsinformatik aufgefasst wer- 
den; vgl. u. a. Heinrich (2001), Schwarzer und Krcmar (2004) sowie WKWI 
(1994). Die Beschreibung beinhaltet die Schaffung eindeutiger terminologi- 
scher Grundlagen, die als Voraussetzung für die Erklärung und Gestaltung 
der Systeme angesehen werden kann, sowie etwa auch das Aufzeigen nicht 
ausgeschöpfter Nutzenpotenziale hinsichtlich IKS. Die Erklärung hat die Ent- 
wicklung von Modellen (Erklärungsmodellen) und Theorien zum Ziel, mit 
deren Hilfe Aussagen über IKS getroffen werden können (z. B. zur Verdeut- 
lichung von Zusammenhängen oder Gesetzmäßigkeiten) . 

Die Gestaltung von IKS umfasst die (Weiter-)Entwicklung entsprechen- 
der Methoden und Werkzeuge sowie den eigentlichen Entwurf und die Rea- 
lisierung einzelner IKS. Grundlage der Gestaltung sind Erklärungsmodelle. 
Insbesondere die Veränderung bestehender Systeme wird (im Gegensatz zur 
Erklärungsaufgabe) meist nicht als wissenschaftliche, sondern als praktische 
Aufgabe angesehen, da mit ihr in der Regel keine Gewinnung neuer Erkennt- 
nisse über den Untersuchungsgegenstand IKS bezweckt wird. Die Entwick- 




1.2 Aufgaben der Wirtschaftsinformatik 



7 



lung von Methoden und Werkzeugen, mit denen IKS erstellt oder verändert 
werden können, zählt jedoch zu den wissenschaftlichen Aufgaben der Wirt- 
schaftsinformatik . 

Die Prognose von IKS hat Voraussagen und Hypothesen über das Ver- 
halten von IKS zum Ziel. Auch hierfür sind Erklärungsmodelle eine unab- 
dingbare Voraussetzung, da die dort verdeutlichten Zusammenhänge und Ge- 
setzmäßigkeiten Aussagen über das wahrscheinliche Verhalten in der Zukunft 
erst ermöglichen. 

Aufbauend auf Erkenntnissen und methodischen Grundlagen sowohl der 
Betriebswirtschaftslehre als auch der (angewandten wie theoretischen) Infor- 
matik ist - neben der Weiterentwicklung entsprechender Theorien und Me- 
thoden - eine primäre Aufgabe der Wirtschaftsinformatik die Analyse und 
Modellierung betrieblicher Gegebenheiten im Hinblick auf die Nutzung einer 
integrierten Informationsverarbeitung (Systemanalyse) und die Entwicklung 
darauf aufbauender Informations- und Kommunikationssysteme. Während 
die eigentliche Softwareentwicklung weiterhin eine wesentliche Aufgabe der 
Wirtschaftsinformatik darstellt, ist heute eine zunehmende Dominanz (be- 
triebswirtschaftlicher) Standardsoftware zu verzeichnen. Ein wesentlicher Ge- 
sichtspunkt in diesem Kontext ist die Entwicklung von (teilweise vom Bran- 
chentyp abhängigen) standardisierten Anwendungssystem- Architekturen. In 
diesem Zusammenhang ergibt sich die Aufgabe, verschiedene Abstraktionen 
der betrieblichen Wirklichkeit, wie eine semantische Gesamtsicht auf die Da- 
ten eines Unternehmens (Unternehmensdatenmodell) oder Modelle betrieb- 
licher Prozesse (Geschäftsprozessmodelle), zu erstellen, zu untersuchen und 
(wieder) zu integrieren. Dabei ist eine geeignete Anpassbarkeit bzw. Kon- 
figurierbarkeit solcher Modelle bzw. Systeme zu berücksichtigen, um einen 
effizienten Einsatz entsprechender Software in der Praxis zu gewährleisten. 

Im Mittelpunkt der Wirtschaftsinformatik in der betrieblichen Praxis 
steht die Konzeption, Entwicklung, Einführung, Nutzung (inklusive der Be- 
nutzerbetreuung) und Wartung von betrieblichen Informationssystemen. All- 
gemein anerkannt ist die zunehmende Bedeutung des Produktionsfaktors - 
der Ressource - Information. Eine heute primäre Zielsetzung bei der Entwick- 
lung und dem Einsatz betrieblicher Informationssysteme ist die effiziente Be- 
friedigung der Informationsnachfrage betrieblicher Aufgabenträger insbeson- 
dere im Hinblick auf die Unterstützung bei Entscheidungsprozessen. Das In- 
formationsmanagement besitzt somit eine zentrale Rolle im Umfeld der Wirt- 
schaftsinformatik. In diesem Zusammenhang sei darauf hingewiesen, dass bei 
einer Zuweisung der Verantwortung für den Produktionsfaktor Information 
an die Wirtschaftsinformatik (vgl. Mertens et al. (2005), S. 3) die Abgrenzung 
zum Informationsmanagement erschwert, wenn nicht gar unmöglich gemacht 
wird. Eine Möglichkeit zur (sinnvollen) Abgrenzung wird in Abschnitt 3.2 
dargestellt; vgl. auch Voß und Gutenschwager (2001). 

Die Nutzung von Informationssystemen bedingt den Aufbau und die Ver- 
waltung einer technischen Informations- und Kommunikationsinfrastruktur 
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sowie das Management der betrieblichen Informationsverarbeitung. Die heu- 
tige betriebliche Praxis ist durch die zunehmende Integration betrieblicher 
Informations- und Kommunikationssysteme in Verbindung mit immer leis- 
tungsfähigeren, aber auch komplexeren Arbeitsplatzrechnern und Laptops 
gekennzeichnet. Dabei besteht nach wie vor das Problem der effizienten Aus- 
stattung, Verwaltung, Integration, Weiterentwicklung und spezifischen Nutz- 
barmachung von Rechnerarbeitsplätzen bzw. der eingesetzten Informations- 
systeme, was insbesondere durch die schnelle Entwicklungsgeschwindigkeit 
der Informationstechnik bedingt ist. Ziel sind hier flexible und leistungsfähi- 
ge Systeme bei gleichzeitiger Berücksichtigung wirtschaftlicher Kriterien. 

Während bisher die Rationalisierung der Unternehmensabläufe im Mit- 
telpunkt der Einführung und Nutzung von IKS stand, wird in Zukunft die 
weitergehende Nutzung von Informations- und Kommunikationstechnik ei- 
ne noch größere Bedeutung gewinnen. Hier sind vor allem Systeme zur 
Unterstützung betrieblicher Kommunikation und Abläufe, wie insbesondere 
(Büro-)Informations- und -kommunikationssysteme zur Unterstützung von 
Gruppenarbeit und Geschäftsprozessen (Workgroup Gomputing und Work- 
flow Management), zu nennen. Weiterhin stellt sich die Aufgabe einer infor- 
mationstechnisch unterstützten Abwicklung von Geschäftsverkehr sowohl mit 
anderen Unternehmen (im Rahmen einer unternehmensübergreifenden Au- 
tomatisierung und Optimierung von Prozessen) als auch mit Konsumenten 
(im Rahmen einer verstärkten Kundenorientierung). Nicht zuletzt muss der 
Planungsunterstützung durch IKS zukünftig eine größere Bedeutung zukom- 
men, da bei zunehmender Globalisierung der Märkte und damit einhergehend 
stärkerem Wettbewerb nicht nur die Informationsbasis für Entscheidungen 
verbessert werden muss, sondern auch die Entscheidungsgüte selbst. 

Durch die zunehmende Bedeutung weltweiter Rechnernetze (wie des Inter- 
nets) bei gleichzeitiger Nutzung kompatibler Techniken in Unternehmensnet- 
zen (Intranets) erwachsen weitere Möglichkeiten. Virtuelle Unternehmungen, 
bei denen zunächst der reale Ort der Arbeitsplätze nicht mehr festgelegt ist, 
werden ermöglicht, bis schließlich bestimmte Arbeitsleistungen nicht mehr 
im Unternehmen vorgehalten werden (müssen), sondern flexibel eingekauft 
werden bzw. zwischenbetrieblich koordiniert und ausgetauscht werden. Das 
heißt, Unternehmen bzw. Unternehmenseinheiten, Institutionen oder Einzel- 
personen kooperieren für eine begrenzte Zeit unter Einbringung von Kern- 
kompetenzen, um spezielle Marktpotenziale im Rahmen einer Leistungser- 
stellung für Dritte flexibel und effizient auszuschöpfen. ^ In Verbindung mit 
Entwicklungen wie dem Electronic Commerce, der elektronischen Abwicklung 
von Geschäftsverkehr, ergeben sich im Zusammenhang mit der Globalisierung 
für Unternehmen sowohl Ghancen als auch Risiken; insbesondere ergibt sich 
eine Zunahme der Markttransparenz und damit ein schärferer Wettbewerb. 
Die Beschäftigung mit diesen Themen bzw. mit den hierfür erforderlichen 

Vgl. z. B. Picot et al. (2003). 
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Informations- und Kommunikationssystemen wird in Zukunft in der Wirt- 
schaftsinformatik weiter an Bedeutung gewinnen. 



1.3 Aufbau dieses Buches 

Der Aufbau dieses Buches ist gemäß der in Abbildung 1.2 gezeigten Ein- 
ordnung der Wirtschaftsinformatik gestaltet. Die aufgrund der obigen Cha- 
rakterisierung zwingende Einordnung der Wirtschaftsinformatik als interdis- 
ziplinäres Fachgebiet, das sich insbesondere Methoden und Erkenntnissen 
der Informatik bedient bzw. dieselben weiterentwickelt und adaptiert, um 
betriebswirtschaftliche Aufgabenstellungen zu lösen, spiegelt sich in der fol- 
genden Buchgliederung wider. 



Wirtschaftsinformatik 



Betriebliche Anwendungssysteme 



Modellierung 



Software- 

entwicklung 



Informations- 

management 



Informatik 



Betriebswirtschaftslehre 



Abb. 1.2. Einordnung der Wirtschaftsinformatik 



Kapitel 2 - Informatik und Informations- und Kommunikationstechnik: Die 
Darlegungen umfassen zum einen die Diskussion theoretischer Aussagen 
hinsichtlich prinzipieller „Grenzen des Machbaren“ (Berechenbarkeit und 
Komplexität von Problemen). Zum anderen werden die Gebiete Codie- 
rung von Informationen als Daten, Hardware, Software, Rechnernetze 
sowie World Wide Web erörtert. 

Kapitel 3 - Informationsmanagement: Die Aufgaben des Informationsma- 
nagements sind von der Grundproblematik einer effektiven und effizi- 
enten Verwendung von Informationen (als Produktionsfaktor) abgelei- 
tet. Entsprechende Anforderungen an die Informationsversorgung in Un- 
ternehmen sind Ausgangspunkt für die konkrete praktische Anwendung 
von Methoden der Wirtschaftsinformatik. In diesem Kapitel werden die 
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Untersuchungsgegenstände und Aufgaben des Informationsmanagements 
dargestellt. Dies bezieht sich insbesondere auf das Management des In- 
formationseinsatzes, der Informations- und Kommunikationssysteme und 
der Informations- und Kommunikationsinfrastruktur sowie auf Interde- 
pendenzen zur Organisationsentwicklung. 

Kapitel 4 - Modellierung: Eine systematische, vereinfachte Abbildung von 
praktischen Gegebenheiten (z. B. Daten, Funktionen, Prozessen) als Mo- 
delle ist die entscheidende Voraussetzung für eine Umsetzung entspre- 
chender Anwendungssysteme. Demzufolge sind Modellierungsmethoden 
zentraler Gegenstand der Wirtschaftsinformatik. Nach einer Einführung 
in die Begriffswelt der Modellierung wird zunächst die Unternehmens- 
modellierung thematisiert. In weiteren Abschnitten werden verschie- 
dene ihrer Teilgebiete, wie die Datenmodellierung (insbesondere die 
Entity-Relationship-Modellierung), die Organisationsmodellierung, die 
funktions- und prozessorientierte Modellierung sowie die objektorientier- 
te Modellierung behandelt. Daran anschließend folgen jeweils eine kurze 
Übersicht zur Simulation und zur mathematischen Modellierung mit be- 
sonderem Augenmerk auf Optimierungsmodellen. 

Kapitel 5 - Datenbanken: Der herausgehobenen Bedeutung von Daten bzw. 
der strukturierten Sammlung und Verwaltung dieser im Rahmen von Da- 
tenbanken als Grundlage betrieblicher Entscheidungsprozesse bzw. An- 
wendungssysteme wird durch einen eigenen Abschnitt Rechnung getra- 
gen. 

Kapitel 6 - Softwareentwicklung: Die für die Wirtschaftsinformatik wesent- 
liche Aufgabe der Entwicklung von (betrieblichen) Informations- und 
Kommunikationssystemen impliziert, dass Methoden zur Entwicklung 
von Software einen Hauptbestandteil jeder Wirtschaftsinformatikausbil- 
dung bilden müssen. Wir erörtern verschiedene Vorgehensmodelle und 
Techniken der Softwareentwicklung. In diesem Rahmen werden auch 
die Softwarewiederverwendung, die Komponententechnik, die Qualitäts- 
sicherung sowie das Projektmanagement thematisiert. 

Kapitel 7 - Betriebliche Anwendungssysteme: In diesem Kapitel werden 
nach der Betonung der bereichsübergreifenden Integrationserfordernis, 
der Diskussion der Gharakteristika entsprechender integrierter Systeme 
und einer Übersicht über Sicherheitsaspekte (insbesondere der Krypto- 
graphie) verschiedene typische betriebliche Bereiche bzw. entsprechen- 
de Anwendungssysteme im Überblick dargestellt. Dies erstreckt sich auf 
klassische Anwendungssysteme in der Industrie (z. B. für die Produkti- 
onsplanung), Anwendungssysteme in Dienstleistungsunternehmen sowie 
im Verkehrsbereich. Weiterhin werden Aspekte des Electronic Gommerce 
betrachtet. 

Anhang: Im Anhang werden einige spezielle Aspekte im Überblick darge- 
stellt: Geschichte der Wirtschaftsinformatik und wissenschaftstheoreti- 
sche Einordnung, Gesellschaften, Publikationsorgane, Tagungen, Berufs- 
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bilder, Informatikrecht (insbesondere Datenschutz) und gesellschaftliche 
Auswirkungen . 

Die Auswahl der in diesem Buch behandelten Inhalte orientiert sich an 
unserer Meinung nach wesentlichen Inhalten der Wirtschaftsinformatik und 
den für deren Verständnis notwendigen Grundlagen bzw. Voraussetzungen. 
Dieses Buch erhebt nicht den Anspruch, die Wirtschaftsinformatik in ihrer 
ganzen Breite und Vielfalt darzustellen, sondern soll insbesondere Studieren- 
den einen Überblick über wichtige Themen der Wirtschaftsinformatik geben 
und auf Basis der angegebenen Literatur einen Einstieg in vertiefende Be- 
trachtungen anbieten. Jedes Kapitel des Buches enthält einige Übungen bzw. 
Kontrollfragen; exemplarische Lösungsvorschläge dazu werden am Ende des 
Buches in einem gesonderten Anhang vorgestellt. 



1.4 Kontrollfragen 

1. Diskutieren Sie verschiedene Schwerpunktsetzungen hinsichtlich der 
Aufgabenfelder der Disziplin Wirtschaftsinformatik! 

2. Überlegen Sie sich eine mögliche sinnvolle Einordnung und Abgrenzung 
der Wirtschaftsinformatik zur Betriebswirtschaftslehre und zur Informa- 
tik! 

3. Grenzen Sie Anwendungssysteme von Informations- und Kommunikati- 
onssystemen ab! 

4. Beschreiben Sie mögliche Vorgänge, die von einer Anlieferung eines Gon- 
tainers per LKW an einem Gontainerterminal bis zu dessen Verschiffung 
durchzuführen sind! Wie lassen sich die Vorgänge durch geeignete IKS 
oder Anwendungssysteme unterstützen? 




2. Informatik und Informat ions- und 
Kommunikationstechnik 



„Informatik wurde in der Vergangenheit zunächst als Spezialgebiet 
innerhalb anderer wissenschaftlicher Disziplinen betrieben, spätes- 
tens seit 1960 kann sie jedoch nicht mehr nur als Ansammlung von 
aus anderen Wissenschaften (z. B. Logik, Mathematik, Elektrotech- 
nik) entliehenen Methoden und Regeln aufgefasst werden; vielmehr 
hat sich die Informatik zu einem zusammenhängenden, theoretisch 
fundierten Gebäude, also zu einer neuen Grundlagenwissenschaft ent- 
wickelt, die auf andere Wissenschaften ausstrahlt. Zugleich führten 
Einsatz und Anwendungen zu einer Fülle von Erkenntnissen, Metho- 
den und Techniken. 

Heute stellt sich die Informatik als eine Ingenieurwissenschaft dar, 
die (anstelle der Grundelemente ,Materie‘ und ,Energie‘) den Roh- 
stoff ,Information‘ modelliert, aufbereitet, speichert, verarbeitet und 
einsetzt.“ (Engesser (1993)) 

In diesem Kapitel werden einige Grundlagen der Informatik und der Infor- 
mations- und Kommunikationstechnik dargestellt. ^ Entsprechende Erkennt- 
nisse und Methoden stellen eine wesentliche Basis für die Wirtschaftsinfor- 
matik dar. 

Der Duden Informatik (Engesser (1993)) definiert Informatik als „Wissen- 
schaft von der systematischen Verarbeitung von Informationen, besonders der 
automatischen Verarbeitung mit Hilfe von Digitalrechnern (Gomputern)“.^ 
Die im Eingangszitat dieses Kapitels vorgenommene Einordnung der Informa- 
tik als Ingenieurwissenschaft ist nicht unumstritten.^ So hat etwa die theo- 

^ Eine umfassende allgemeinverständliche Beschreibung von Informations- nnd 
Kommunikationstechnik findet sich z.B. in Petzold (1999) sowie Nisan und 
Schocken (2005). 

^ Demzufolge wird der Begriff Information in den Mittelpunkt gestellt. Dies erfor- 
dert eine entsprechende Auseinandersetzung mit diesem Begriff; vgl. hierzu das 
entsprechende Stichwort in Engesser (1993) sowie Kapitel 3. 

® In diesem Zusammenhang sei auch auf die Divergenz zwischen den Inhalten 
einer Hochschulausbildung Informatik und dem praktischen Berufsbild hinge- 
wiesen. Die klassischen Tätigkeiten eines Informatikers in der Praxis (Konzep- 
tion, Erstellung und Betrieb von Informationssystemen) sind durchaus als Inge- 
nieurtätigkeiten zu verstehen. 
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retische Informatik viele Gemeinsamkeiten mit der als Formalwissenschaft 
klassifizierbaren Mathematik:"^ 

• Abstraktheit mit vielen verschiedenen Abstraktionsniveaus 

• Präzision und logische Strenge 

• quantitative Aussagen 

• breites, nahezu universelles Anwendungsgebiet 

Anders als die Mathematik sind die betrachteten Strukturen aber im We- 
sentlichen dynamisch; Algorithmen (anstatt statischer Beziehungen) stehen 
im Mittelpunkt. Demzufolge sprechen Aho und Ullman (1996), S. 19, auch 
treffend von der Informatik als der Wissenschaft von der „Mechanisierung 
der Abstraktion“. Diese Charakterisierung erlaubt eine Interpretation, die 
die traditionellen Teilgebiete der Informatik (theoretische, technische und 
praktische Informatik) umfasst. Es ist jedoch zu konstatieren, dass die In- 
formatik als relative junge, heterogene Wissenschaftsdisziplin eine eindeutige 
und klar umrissene Definition und Abgrenzung (noch) nicht zulässt. 

Im nächsten Abschnitt werden einige wesentliche theoretische Grundla- 
gen der Informatik in vereinfachter Form dargelegt. Dabei wird sich ins- 
besondere zeigen, dass es auch unter Nutzung leistungsfähigster Rechner 
prinzipielle „Grenzen des Machbaren“ gibt. Das heißt, auch eine Fortset- 
zung der raschen Entwicklung der Informations- und Kommunikationstech- 
nik (gebräuchlicherweise abgekürzt durch IT) wird nur sehr bedingt zu einer 
universellen Problemlösungsfähigkeit führen. Hingegen bietet die IT insbe- 
sondere ein „ermöglichendes Instrumentarium“ für eine Neugestaltung und 
(Teil-)Automatisierung von Prozessen {Enabling- Funktion) im Hinblick auf 
das von Mertens (1995) formulierte Langfristziel der Wirtschaftsinformatik, 
der sinnhaften Vollautomation. 



2.1 Theoretische Grundlagen 

Dem Laien werden aufgrund der atemberaubend schnellen Entwicklung in 
verschiedenen Bereichen der Informations- und Kommunikationstechnik so- 
wie bei modernen Informationssystemen oftmals Möglichkeiten suggeriert, die 
nach derzeitigem Kenntnisstand teilweise nicht haltbar sind. Das heißt, nicht 
jedes (Planungs-)Problem lässt sich mal eben schnell im Vorbeigehen lösen, 
indem man die auftretenden Prozesse modelliert (vgl. Kapitel 4) und die 
Probleme einem Rechner überträgt. Warum dies so ist, beantwortet insbeson- 
dere die Komplexitätstheorie. Im Folgenden beschreiben wir hierzu zunächst 
einige Grundlagen der Berechenbarkeitstheorie und gehen dann auf einfache 
Aspekte der Komplexitätstheorie ein. Dabei zeigen wir auf, dass es sinnvoll 
sein kann, sich bei der Lösung von Problemen auf Näherungslösungen zu 
beschränken.^ 

^ Vgl. Rechenberg (2000), S. 271, sowie Anhang A.2. 

® Vgl. z.B. Fink und Voß (1998) sowie Vollmer (1999). 
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2.1.1 Berechenbarkeit 

Die zentrale Frage der Berechenbarkeitstheorie lautet: 

Gibt es prinzipielle Grenzen der Berechenbarkeit? 

Die Auseinandersetzung mit dieser Frage erfordert die Klärung des Begriffes 
Berechenbarkeit.^ Hierzu sei von folgender Fragestellung ausgegangen: Ziel 
ist die Berechnung einer Funktion f : M N für zwei Mengen M und N . 
Ein einfaches Beispiel hierfür ist die Überprüfung, ob eine natürliche Zahl 
eine Primzahl ist; M ist dann die Menge der natürlichen Zahlen, die Ergeb- 
nismenge N ist {ja, nein}. Eine möglicherweise komplexere Aufgabe wäre die 
Entwicklung eines Verfahrens, das einen Text von einer Sprache in eine ande- 
re übersetzt. Eine Funktion bzw. ein Problem wird als 6erec/ien&or definiert, 
wenn ein Algorithmus existiert, der für jeden Eingabe wert m & M nach end- 
lich vielen Schritten anhält und als Ergebnis /(m) liefert. Diese Definition 
erfordert eine Auseinandersetzung mit dem Begriff Algorithmus. 

Informell sei ein Algorithmus definiert als eine mit (semi-)formalen Mitteln 
eindeutig beschreibbare, effektiv nachvollziehbare Verarbeitungsvorschrift zur 
Lösung einer Klasse von Problemen im Sinne der Transformation von Ein- 
gabedaten in Ausgabedaten. Es gibt verschiedenste Konkretisierungen bzw. 
Formalisierungen, durch die ein Algorithmus dargestellt werden kann: Pro- 
grammiersprachen (z. B. Pascal, C-l— I-, Java, C#, Smalltalk), mathemati- 
sche Kalküle (z. B. /i-rekursive Funktionen), Maschinenmodelle (z. B. Turing- 
Maschine, Pentium-Prozessor) usw. Damit stellt sich die Frage, inwieweit die 
Berechenbarkeit eines Problems von dem verwendeten Modell abhängig ist. 
Es hat sich jedoch gezeigt, dass alle bisher untersuchten Konkretisierungen 
des Begriffes Algorithmus gleich mächtig sind im Hinblick auf die prinzipi- 
elle Berechenbarkeit von Problemen. Dies wird in der Ghurchschen These 
folgendermaßen formuliert: 

Jede im intuitiven Sinne berechenbare Funktion 
ist Turing-berechenbar. 

Als Turing-berechenbar hezeidmet man dabei die Probleme, die auf dem klas- 
sischen Maschinenmodell der theoretischen Informatik, der Turing-Maschine, 
berechnet werden können. Anstatt dieses Modell darzustellen, sei hier ein ein- 
facheres Modell zu Grunde gelegt, die WHILE-Programmiersprache, die nur 
die folgenden vier Operationen umfasst: 

a: := 0; 
a; := a; -I- 1 ; 
a; := a; — 1 ; 

while X y do ... end; 

® Vgl. für die folgenden Darlegungen z. B. Engesser (1993), Harel (2000), Rechen- 
berg (2000) und Wegener (1999). 




16 



2. Informatik und Informations- und Kommunikationstechnik 



Das heißt, man kann Variablen definieren (hier z. B. x), denen lediglich 
der Wert null direkt zugewiesen werden kann. Durch zwei weitere Operatio- 
nen kann der Wert einer Variablen um eins erhöht bzw. verringert werden. 
Operationen werden durch Semikola abgeschlossen. Die while-Operation wie- 
derholt die durch do und end eingeschlossene Operationssequenz solange, wie 
die zu vergleichenden Variablen ungleich sind. Man kann sich überlegen, dass 
bekannte mächtigere Befehle aus diesen Elementaroperationen konstruierbar 
sind. So kann man eine Addition 

X := X + y, 

über folgendes kurzes WHILE-Programm durchführen: 
z := 0 ; 

while z ^ y ÖlO X -.= X + 1\ z:=z+l; end; 

Nunmehr kann man Multiplikationen über wiederholte Additionen ab- 
bilden usw. Es hat sich herausgestellt, dass man die Konstrukte hö- 
herer Programmiersprachen auf die Elementaroperationen der WHILE- 
Programmiersprache zurückführen kann. Damit besagt obige These anschau- 
lich, dass man zu jedem in irgendeiner sinnvollen Form spezifizierten Algo- 
rithmus ein entsprechendes WHILE-Programm konstruieren kann, das die 
gleiche Funktion berechnet. Gleichermaßen lässt sich jeder in irgendeinem 
Formalismus dargestellte Algorithmus in einen entsprechenden Algorithmus 
eines beliebigen anderen Formalismus transformieren. 

Die Churchsche These ist kein mathematischer Satz, da der Begriff der 
„im intuitiven Sinne berechenbaren Funktion“ nicht präzisiert werden kann. 
Da aber bisher alle Versuche gescheitert sind, die Churchsche These zu wi- 
derlegen, wird sie heute allgemein anerkannt. Man geht daher davon aus, 
dass sich alle Programmiersprachen und Computermodelle hinsichtlich der 
prinzipiellen Berechenbarkeit von Problemen gleichen. 

Nachdem der Begriff Berechenbarkeit charakterisiert wurde, können wir 
auf die Ausgangsfrage „Gibt es prinzipielle Grenzen für Berechenbarkeit?“ 
zurückkommen. Ein einfaches Argument weist nach, dass Funktionen existie- 
ren, die nicht berechenbar sind: Es gibt nur abzählbar viele Algorithmen, 
da alle Algorithmen als abzählbar viele WHILE-Programme formulierbar 
sind. Andererseits gibt es überabzählbar viele Funktionen f : M ^ N, wie 
man über eine einfache Diagonalisierung zeigen kann. (Die Argumentation 
ist hier analog zu dem Beweis von Cantor, dass die Menge der reellen Zahlen 
überabzählbar ist, d. h. die Elemente der Menge lassen sich nicht fortlaufend 
nummerieren.) Damit existieren unendlich viele solcher nichtberechenbarer 
Funktionen. Das berühmteste nichtberechenbare Problem ist das so genann- 
te 



Halteproblem: Gibt es ein Programm, das entscheidet, ob ein belie- 
biges gegebenes Programm für beliebige Eingabeparameter anhält 
(terminiert)? 




2.1 Theoretische Grundlagen 



17 



Man kann zeigen, dass dieses Problem in seiner Allgemeinheit nicht lösbar ist; 
vgl. z. B. Engesser (1993). Diese fundamentale Aussage zeigt, dass wohldefi- 
nierte Probleme existieren, die aus prinzipiellen Gründen nicht lösbar sind. 
Im Gegensatz zu vielen anderen Problemen, die wegen ihres Umfanges o. A. 
praktisch nicht lösbar sind (s.u.), handelt es sich hier um eine Aussage über 
die endgültigen, praktischen wie theoretischen Grenzen des algorithmisch Be- 
rechenbaren. Dieses Ergebnis hat auch weitreichende praktische Folgerungen: 
So kann man etwa auch zeigen, dass kein Algorithmus existieren kann, der 
Programme im Allgemeinen hinsichtlich ihrer semantischen Korrektheit über- 
prüft. 

2.1.2 Komplexität 

Während im Zusammenhang mit der Berechenbarkeitstheorie Existenzaussa- 
gen im Mittelpunkt stehen, untersucht die Algorithmen- und Komplexitäts- 
theorie Fragestellungen hinsichtlich des Aufwandes, der zur Berechnung eines 
Problems anfällt. ^ Dabei stehen Aussagen bezüglich der Rechenzeit (Rechen- 
aufwand, Laufzeit) im Mittelpunkt - weitere Ressourcen sind z.B. Speicher- 
platz oder Kommunikationsaufwand -, wobei in der Regel die Anzahl aus- 
geführter Elementaroperationen als Berechnungs- bzw. Messgröße zu Grunde 
gelegt wird (wie z.B. Addition oder Vergleich zweier Zahlen mit begrenzter 
Stellenzahl) . 

Zur Quantifizierung der Laufzeit von Algorithmen verwendet man in der 
Regel die asymptotische Laufzeitkomplexität. Dabei begnügt man sich unter 
Verwendung der so genannten 0-Notation mit „groben“ Aussagen zum Lauf- 
zeitverhalten „für große n“, wobei n die Problemgröße beschreibt. Oftmals 
erscheint die Angabe der Problemgröße offensichtlich. So mag sich die Be- 
schreibung der Problemgröße für die Sortierung von n Zahlen durch n sofort 
aufdrängen; allerdings bleibt dabei unberücksichtigt, dass sich für jede ein- 
zelne Zahl in Abhängigkeit von der Größe oder der Genauigkeit eventuell 
ein nicht konstanter Speicheraufwand ergibt. Als weiteres Beispiel diene die 
Addition zweier n x n Matrizen: Obwohl die Eingabelänge hierfür eigentlich 
2 ■ n ■ n ■ d beträgt, wobei d die benötigte Speicherlänge für ein Matrixele- 
ment ist, gibt man den Berechnungsaufwand in der Regel für den primär 
kennzeichnenden Parameter n an. 

Eine asymptotische Laufzeitkomplexität von T{n) = 0{ri^) bedeutet, dass 
die Laufzeit eines Algorithmus für genügend große Werte von n durch eine 
Funktion c- , c konstant, nach oben beschränkt ist. Formal lässt sich dies 
folgendermaßen spezifizieren: T(n) = 0{f{n)) 3c > 0 3n' > 0 > n' : 

T(n) < c ■ f{n). Einige typische Laufzeitklassen seien im Folgenden kurz 
charakterisiert: 

^ Vgl. hierzu z.B. Bachem (1980), Engesser (1993), Garey und Johnson (1979), 
Papadimitriou (1994), Rechenberg (2000) und Wegener (1999). 
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• 0(1), konstanter Aufwand: Die Laufzeit ist konstant bzw. von der Prob- 
lemgröße unabhängig. 

• 0(log n), logarithmische Komplexität: Eine Verdopplung der Eingabegröße 
des Problems führt hier nur zu einem Anstieg der Laufzeit um eine Kon- 
stante. Ein Beispiel für einen solchen Algorithmus ist die binäre Suche 
eines Elementes in einer geordneten Sequenz von Zahlen (sukzessive ver- 
gleichend mit einem mittleren Element der verbliebenen Sequenz werden 
die zu betrachtenden Zahlen in jedem Schritt in etwa halbiert). 

• 0(n), lineare Komplexität: Die Laufzeit ist proportional zur Problemgröße. 
Beispiel: Suche eines Elementes in einer ungeordneten Menge von Zahlen. 

• O(nlogn): Diese Laufzeitkomplexität ist typisch für Algorithmen zur Sor- 
tierung von n Objekten. 

• 0(n^), k konstant, polynomiale Komplexität: Solche Laufzeitkomple- 
xitäten sind typisch für Algorithmen mit k geschachtelten Schleifen, die 
jeweils mit einer von n abhängigen Häufigkeit durchlaufen werden. 

• 0(2"), exponentielle Komplexität: Die Laufzeit solcher Algorithmen 
wächst so stark an, dass sie für „große n“ nicht mehr brauchbar sind. 

Die asymptotische Laufzeitkomplexität charakterisiert das Laufzeitver- 
halten eines Algorithmus nur grob. Weiterhin wird bei solchen Aussagen in 
der Regel der Worst Case angenommen; d. h. es wird eine obere Abschätzung 
für den schlimmstmöglichen Fall getroffen. Im praktischen Einsatz kann da- 
mit ein Verfahren mit einer Komplexität von 0{n?) im Durchschnitt besser 
abschneiden als eines mit O(nlogn). Dies sei an folgendem Beispiel verdeut- 
licht: Als Sortieralgorithmus wird häufig der Quicks ort- Algorithmus einge- 
setzt; vgl. z.B. Cormen et al. (2004). Es gibt einige Eingaben, für die der 
Quicksort-Algorithmus zur Sortierung von n Zahlen eine Laufzeit von O(n^) 
benötigt; zumeist liegt die Laufzeit aber bei O(nlogn). Da der Quicksort- 
Algorithmus relativ einfach zu implementieren und die im großen O „versteck- 
te“ Konstante relativ klein ist, wird dieser Algorithmus in der praktischen 
Anwendung oft anderen Sortieralgorithmen vorgezogen, die eine Worst-Case- 
Komplexität von 0(n log n) besitzen. 

Die Vorteilhaftigkeit eines Verfahrens ist damit eigentlich eher über die 
durchschnittliche Laufzeit zu bewerten {Average Case). Allerdings ergeben 
sich hierbei im Allgemeinen zwei Probleme: Zum einen ist die Kenntnis der 
Wahrscheinlichkeitsverteilung der Eingaben notwendig, zum anderen ergeben 
sich in der Regel bei nichttrivialen Algorithmen erhebliche Schwierigkeiten bei 
der Bestimmung des durchschnittlichen Berechnungsaufwandes. 

Eine weitere relevante Möglichkeit der Quantifizierung des Berechnungs- 
aufwandes besteht in der amortisierten Laufzeitanalyse, bei der der Aufwand 
einer wiederholten Ausführung gewisser Operationen berechnet wird. Dies sei 
durch ein Beispiel erläutert: Obwohl der Aufwand einer einzelnen Operation 
im Worst Case linear sein mag (z. B. die Erweiterung eines Vektors um ein 
Element über den bereits reservierten Speicherbereich hinaus), können nach- 
folgende Operationen oftmals mit konstantem Aufwand ausgeführt werden 
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(z. B. indem eine nötige Erweiterung eines Vektors über eine Verdopplung 
des reservierten Speicherbereiches durchgeführt wird), so dass sich amorti- 
siert ein konstanter Aufwand für die Operationsausführung ergeben kann. 

Zur Verdeutlichung der Auswirkungen verschiedener Laufzeitkomplexi- 
täten kann Tabelle 2.1 dienen, die für gewisse Laufzeitkomplexitäten und 
Rechenzeiten die maximal lösbare Problemgröße n angibt. Dabei sei davon 
ausgegangen, dass in einer Millisekunde eine Elementaroperation ausgeführt 
wird. Man erkennt, dass insbesondere bei der exponentiellen Laufzeitkomple- 
xität eine Erhöhung der Rechenzeit nur relativ geringe Auswirkungen auf die 
lösbare Problemgröße nach sich zieht. 



Komplexität 


1 Sekunde 


Rechenzeit 
1 Minute 


1 Stunde 


n 


n = 1.000 


n = 60.000 


n = 3.600.000 




n = 31,6 


n = 244,9 


n = 1.897,4 


2" 


n = 10,0 


n = 15,9 


n = 21,8 



Tabelle 2.1. Maximal lösbare Problemgröße n in Abhängigkeit von Laufzeitkom- 
plexität und Rechenzeit 



Komplexität 


Rechenzeit 

1 Sekunde auf altem Computer 1 Sekunde auf neuem Computer 


n 


«alt = 1000 




^neu ' — 2.000 — 2 • /Zalt 




Malt = 31,6 




^neu 44,7 • TT-alt 


2" 


Malt = 10,0 




^neu - — 11,0 — ^alt 1 



Tabelle 2.2. Veränderung der maximal lösbaren Problemgröße n in Abhängigkeit 
von Laufzeitkomplexität und Computergeschwindigkeit 



Der entsprechende Zusammenhang ist in Tabelle 2.2 veranschaulicht, in- 
dem der Effekt einer Verdopplung der Rechnergeschwindigkeit hinsichtlich 
der Problemgrößen, die in einer Sekunde berechenbar sind, dargestellt wird. 
Dabei wird die Annahme zu Grunde gelegt, dass in einer Millisekunde auf 
dem alten Computer eine, auf dem neuen Computer dagegen zwei Elemen- 
taroperationen ausgeführt werden können. Man erkennt, dass bei einer expo- 
nentiellen Laufzeitkomplexität eine Steigerung der Rechnergeschwindigkeit 
die lösbare Problemgröße nur geringfügig erhöht. Hieraus leitet sich aus ei- 
ner praktischen Sichtweise eine Klassifikation von Laufzeitkomplexitäten bzw. 
Algorithmen in zwei Gruppen ab. Alle Algorithmen mit einer Laufzeitkomple- 
xität von maximal O(n^) für ein konstantes k bezeichnet man als polynomial, 
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alle mit einer Laufzeitkomplexität von 0{p^) für ein konstantes p bezeichnet 
man als exponentiell. Während exponentielle Algorithmen auch mit schnel- 
leren Rechnern für große Probleme in der Regel nicht mehr brauchbar sind, 
werden die polynomialen Verfahren zusammenfassend als effizient bezeichnet. 

Bei den bisherigen Darlegungen stand die Komplexitätsabschätzung für 
einen gegebenen Algorithmus „nach oben“ im Mittelpunkt. Eine interessan- 
te Verallgemeinerung besteht darin, Komplexitätsabschätzungen für Proble- 
me anstatt für Algorithmen anzugeben. So besitzt der Standardalgorithmus 
für die Multiplikation zweier n x n Matrizen eine Komplexität von O(n^). 
Während die Frage, ob es auch schneller geht, durch Angabe und Unter- 
suchung eines entsprechenden Algorithmus teilweise beantwortbar ist, erfor- 
dert eine Komplexitätsabschätzung „nach unten“ andere Techniken. Untere 
Schranken werden als 17 (. . .) angegeben. Da eine Matrizenmultiplikation alle 

Matrixelemente der Ergebnismatrix erzeugen muss, ergibt sich eine trivia- 
le untere Schranke von I7(n^). Eine Zielsetzung der Komplexitätstheorie ist 
es, die exakte Laufzeitkomplexität von Problemstellungen, die über 0(. . .) 
ausgedrückt wird, zu bestimmen.® 

Während die Bestimmung der exakten Problemkomplexität im Bereich 
der polynomialen Funktionen oft eher von theoretischem Interesse ist, ist 
es für viele Problemstellungen offen, ob sie überhaupt effizient lösbar sind 
(d. h. mit einem Algorithmus mit polynomialer Laufzeit). Mit V bezeichnet 
man die Komplexitätsklasse aller Probleme, die effizient lösbar sind. Alle bis- 
her angesprochenen konkreten Probleme (Sortieren, Matrizenmultiplikation 
usw.) liegen in V. Auch folgende Problemstellung ist effizient lösbar: Man 
betrachte den in Abbildung 2.1 dargestellten Graphen, der ein Verkehrsnetz- 
werk repräsentiere. Die Knoten repräsentieren Standorte, die eingezeichne- 
ten Verbindungen stellen die existierenden Verkehrswege mit den entspre- 
chenden Entfernungen dar. Das Kürzeste- Wege-Problem (vgl. u. a. Domschke 
und Drexl (2005)) besteht darin, den kürzesten Weg von einem gegebenen 
Start- zu einem gegebenen Zielstandort zu bestimmen. Beispielsweise sei der 
kürzeste Weg vom Knoten 1 zum Knoten 8 gesucht. Für diese Problemstel- 
lung existieren Verfahren mit einem Zeitaufwand von wobei n die 

Anzahl der Knoten bezeichnet. 

Das Rundreiseproblem (Problem des Handlungsreisenden, Traveling- 
Salesman- Problem) ist relativ ähnlich zum Kürzeste- Wege-Problem: Für 
einen gegebenen Graphen (der wie beim Kürzeste- Wege-Problem Standorten 
und Verkehrsverbindungen mit ihren Entfernungen entspricht) ist eine Rund- 
reise durch alle Standorte zu bestimmen, so dass die insgesamt zurückgelegte 
Strecke (Gesamtstrecke) minimal ist. Für die optimale Lösung dieser Prob- 
lemstellung sind jedoch nur exponentielle Algorithmen bekannt. Ein weiteres 
solches Problem, für das keine effizienten Algorithmen bekannt sind, ist das 



Die exakte Laufzeitkomplexität der Matrizenmultiplikation ist unbekannt, 
während zumindest entsprechende Algorithmen mit einem Aufwand von 
0(n^’®^®) bekannt sind; vgl. Cormen et al. (2004). 
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Steiner-Problem in Graphen. Zielsetzung ist die Bestimmung eines Teilgra- 
phen mit minimaler Gesamtstrecke derart, dass alle Knotenpaare aus einer 
ausgezeichneten Teilmenge der Knoten des Graphen miteinander verbunden 
sind. 

Für das im Folgenden beschriebene Investitionsauswahlproblem sind eben- 
falls keine effizienten Algorithmen bekannt. In der Unternehmenspraxis stellt 
sich oft das Problem der effizienten Auswahl unter einer Menge von poten- 
ziell durchführbaren Investitionsvorhaben, zwischen denen gewisse Zusam- 
menhänge bestehen. Beispielsweise können sich zwei Investitionsvorhaben ge- 
genseitig ausschließen, gegenseitig bedingen oder wechselseitige, nicht exakt 
quantifizierbare Kosten- oder Erfolgsauswirkungen besitzen. Folgende einfa- 
che Abstraktion aus diesem Bereich ist wohlbekannt: Jedes Investitionsvorha- 
ben besitzt einen bestimmten Kapitalwert et und verursacht eine 

Reihe von Nettoauszahlungen an, die in Periode t, 1 < t < T, anfallen, wenn 
die jeweilige Investition durchgeführt wird. Für jede Periode t ist dabei ein 
maximales Budget bt vorgegeben, welches nicht überschritten werden darf. 
Das Problem besteht darin, unter Einhaltung der Budgetrestriktionen in al- 
len Perioden eine Auswahl der durchzuführenden Investitionen so zu treffen, 
dass der Gesamtkapitalwert maximiert wird. 

Es gibt eine große Anzahl von Problemstellungen, die ähnlich wie das 
Rundreiseproblem, das Steiner-Problem in Graphen und das Investitionsaus- 
wahlproblem folgende Eigenschaft besitzen: Man kann effizient eine Lösung 
raten (nichtdeterministisch erzeugen) und überprüfen, ob der Zielfunktions- 
wert kleiner als eine vorgegebene Schranke ist. Die entsprechende Problem- 
klasse für solche Entscheidungsprobleme wird mit AfV bezeichnet.® AfV stellt 
trivialerweise eine Obermenge von V dar.^® Es gibt eine Vielzahl an relevan- 
ten Problemen, die in AfV enthalten sind, für die man aber bisher keinen 
effizienten Algorithmus kennt, sondern nur solche mit exponentiellem Auf- 

® AfV steht für nichtdeterministisch polynomial und ist als die Klasse aller Proble- 
me definiert, die auf einer nichtdeterministischen Turing-Maschine in polynomial 
beschränkter Laufzeit berechnet werden können. 

Hierbei vernachlässigen wir die eigentlich erforderliche Unterscheidung in 
Optimierungs- und Entscheidungsprobleme. 
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wand. Diese „schweren“ Probleme in J\fV werden als MV -schwer oder auch 
als nicht handhabbar (intractahle) bezeichnet (mit einigen Ausnahmen). In- 
teressanterweise sind alle A/”7^-schweren Probleme in einem gewissen Sinne 
„gleich schwer“. Man kann zeigen, dass dann, wenn man auch nur für eine 
dieser Problemstellungen ein effizientes Verfahren angeben kann, auch die 
übrigen effizient lösbar sind. Bisher ist aber weder dies gelungen, noch konn- 
te man nachweisen, dass zur Lösung AfT^-schwerer Probleme keine effizienten 
Algorithmen existieren. Die Frage „V = stellt das Hauptproblem der 

Komplexitätstheorie dar. Obwohl dieses Problem bisher nicht gelöst werden 
konnte, geht man aufgrund der umfangreichen (erfolglosen) Forschungsan- 
strengungen im Hinblick auf effiziente Algorithmen für AfT^-schwere Probleme 
davon aus, dass für solche Probleme keine effizienten Algorithmen existieren. 

2.1.3 Heuristiken 

Die oben getroffenen Aussagen zur Schwierigkeit der Lösung gewisser Prob- 
lemstellungen lassen teilweise eine Relativierung des Lösungsbegriffes als 
zweckmäßig erscheinen. Bei der Definition „Probleme, für deren Lösung ein 
polynomialer Algorithmus existiert, werden als effizient lösbar bezeichnet“, 
wird in der Regel implizit zu Grunde gelegt, dass mit Lösung die exakte Be- 
stimmung einer optimalen Lösung gemeint ist. Aus den obigen Darlegungen 
ergab sich, dass es auch unter Nutzung leistungsfähigster Rechner prinzipiel- 
le Grenzen des theoretisch wie auch praktisch Machbaren gibt. Damit bleibt 
für die praktische Lösung gewisser Probleme in der Regel nur die Aufga- 
be bzw. die Vernachlässigung des Optimalitätskriteriums. Man begnügt sich 
dann mit approximativen Verfahren, so genannten Heuristiken, die effizient 
(d. h. mit polynomialem Rechenaufwand) über die Anwendung als sinnvoll 
erachteter Vorgehens weisen systematisch möglichst gute, aber gegebenenfalls 
nicht optimale Lösungen erzeugen. 

Aus praktischer Sichtweise mag für ein gewisses Anwendungsbeispiel die 
Bestimmung einer zulässigen Lösung mit der Garantie, dass diese höchstens 
1% vom optimalen Zielfunktionswert entfernt liegt, vollkommen ausreichend 
sein - auch im Hinblick auf eine im Allgemeinen vorhandene Ungenauig- 
keit der Eingabedaten wie auch der Problemmodellierung. Demzufolge ist 
die komplexitätstheoretische Untersuchung von approximativen Algorithmen 
oder heuristischen Verfahren ein wichtiger praxisrelevanter Forschungsbe- 
reich. Selbst wenn es auch hier theoretische Aussagen z. B. dahingehend gibt, 
dass die Approximationsgüte effizienter Verfahren für gewisse Problemstel- 
lungen im Warst Case nicht beliebig gesteigert werden kann, sind solche Aus- 
sagen für praktische Probleme doch nur bedingt gewichtig. So relativieren die 
Erfolge von modernen heuristischen Verfahren (so genannten Metaheuristi- 
ken) wie u. a. Genetische Algorithmen und Tabu Search bei der Anwendung 
auf praktische Problemstellungen die theoretischen Aussagen doch in einem 
gewissen Maße; vgl. z.B. Rayward-Smith et al. (1996) oder Voß et al. (1999). 
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2.2 Codierung von Informationen als Daten 

Die Abbildung von Informationen (wie Zahlen, Texte, Bilder, Filme, Töne 
u.Ä.) in Rechnern erfordert die Definition und Anwendung von Codierungs- 
vorschriften, mittels derer Informationen in Daten transformiert werden. 
Dabei werden im Allgemeinen Informationen in Form von Sequenzen von 
Zeichen (Symbolen) aus einer bestimmten Zeichenmenge (Alphabet) abge- 
bildet. Beispiele hierfür sind folgende Abbildungen: 

• natürliche Zahlen als Sequenzen von Ziffern aus {0, 1, . . ., 9} 

• Wörter bzw. Texte als Buchstabensequenzen aus {a, b, c, . . ., z, A, B, C, 

...,Z} 

• Schulnoten als Elemente aus der Menge {sehr gut, gut, befriedigend, aus- 
reichend, mangelhaft, ungenügend} 

• Jahreszeiten als Elemente aus der Menge {Frühling, Sommer, Herbst, Win- 
ter} 

Da Rechnersysteme auf der Darstellung von Informationen auf Basis der 
elementaren Informationseinheit Bit {Binary Digit) aufbauen, werden hier al- 
le Informationen letztendlich binär codiert. Das heißt, es wird eine binäre Zei- 
chenmenge aus zwei Zuständen verwendet; in der Regel ist dies die Binärzei- 
chenmenge {0,1}.^^ Technisch entspricht die Binärzeichenmenge etwa der 
Unterscheidung zwischen zwei Zuständen der Art „Spannung bzw. Ladung 
höher oder niedriger als ein Schwellwert“. Die allgemeine Abbildbarkeit von 
(diskreten) Informationen im Binärsystem ergibt sich aus der grundlegen- 
den Erkenntnis, dass sich Symbole beliebiger Zeichenmengen als Gruppen 
von Binärzeichen ausdrücken lassen. Beispielsweise kann man Jahreszeiten 
im Binärsystem über folgende Zuordnungsvorschrift (Code) abbilden: 

• Frühling ^ 00 

• Sommer ^01 

• Herbst ^ 10 

• Winter ^11 

Mittels n Binärzeichen lassen sich 2" Kombinationen bilden und dementspre- 
chend 2” verschiedene Informationen abbilden. 

Die grundlegende Codierung von natürlichen Zahlen basiert auf dem Stel- 
lenwertsystem. Dabei wird der Wert der einzelnen Symbole (Ziffern) einer 
Zahl entsprechend ihrer Stellung innerhalb der Zahl gewichtet. Ein konkretes 

In diesem Abschnitt verwenden wir zunächst eine umgangssprachliche Definition 
der Begriffe Information und Daten. In Abschnitt 3.1.2 erfolgt eine erweiterte 
Begriffsdefinition und Abgrenzung. 

Statt {0,1} sind auch die Darstellungen {Ja, Nein}, {An, Aus}, {True, False} 
usw. gebräuchlich. Beispiele für andere Binärsysteme sind das Morsesystem 
({kurz, lang}) oder Fußgängerampeln ({grün, rot}). 
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Zahlensystem ergibt sich durch Definition einer Basis B und einer entspre- 
chenden Zeichenmenge aus B Ziffern {0,1,. ..,-B — 1}. Der Wert einer n- 
stelligen Zahl a, die allgemein als eine Sequenz von Ziffern aus (0, 1, ... , B—1} 
dargestellt wird, berechnet sich wie folgt: 



n — 1 

a„_ia „_2 . . . ßo ^ Wert a = 

i=0 

Dabei werden die Ziffern konventionsgemäß von rechts nach links, beginnend 
mit 0 durchnummeriert; d. h. die höchstwertige Ziffer steht ganz links. Ge- 
bräuchlich sind im Wesentlichen folgende Zahlensysteme: 

• Dualsystem: B=2, Ziffernmenge (0, 1} 

• Oktalsystem: B=8, Ziffernmenge (0, 1, . . ., 7} 

• Dezimalsystem: B=10, Ziffernmenge (0, 1, . . ., 9} 

• Hexadezimalsystem: B=16, Ziffernmenge (0, 1, . . ., 9, A, . . ., F} 

Beispielsweise wird die (dezimale) Zahl 83 im Dualsystem als 

01010011 = 0 • 2^ -k 1 • 2® -k 0 • 2® -k 1 • 2^ -k 0 • 2^ -k 0 • 2^ -h 1 • 2^ -k 1 • 2° 

dargestellt. Zur Angabe des verwendeten Zahlensystems kann man einen ent- 
sprechenden Index nutzen (83dez, OlOlOOllduai)- Acht Bit (z. B. acht Ziffern 
einer Dualzahl) werden zu einem Byte zusammengefasst; mit einem Byte 
lassen sich folglich 2® = 256 verschiedene Informationen abbilden, z. B. der 
Zahlenbereich [0, . . ., 255]. Aus der Basiseinheit Byte lassen sich bilden: 

• Kilobyte: 1 KB = 2^® Byte = 1024 Byte 

• Megabyte: 1 MB = 2^® Byte = 1.048.576 Byte 

• Gigabyte: 1 GB = 2®® Byte = 1.073.741.824 Byte 

• Terabyte: 1 TB = 2^0 Byte = 1.099.511.627.776 Byte 

• Petabyte: 1 PB = 2®° Byte = 1.125.899.906.842.624 Byte 

• Exabyte: 1 EB = 2®® Byte = 1.152.921.504.606.846.976 Byte 

Diese Einheiten weichen damit von den „Standardeinheiten“ k = 10®, M = 
10® usw. leicht ab.®® 

Ganze Zahlen können im Rechner über eine Konvertierung von einer 
Dezimalzahl in eine Dualzahl abgebildet werden. Der abbildbare Zahlenbe- 
reich ist dementsprechend abhängig von der Anzahl der genutzten Bits bzw. 
Bytes. Oftmals wird dabei die Länge eines rechnerabhängigen Maschinen- 
wortes (mehrere Byte (z.B. 4), mit der ein Rechner effizient als Einheit um- 
gehen kann) verwendet. Zur Darstellung negativer Zahlen könnte man ein 
ausgezeichnetes Bit (z.B. das ganz links) verwenden, das angibt, ob die Zahl 

®® Allerdings ist auch die entsprechende Verwendung im EDV-Bereich (EDV : Elekt- 
ronische Datenverarbeitung) teilweise uneinheitlich. So wird beispielsweise die 
Kapazität von Festplatten oft ausgehend von 1 kB = 1000 Byte ausgedrückt; 
gleiches gilt für die Angabe von Bandbreiten; vgl. Abschnitt 2.5.1. 
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negativ Beispielsweise erhält man bei einer Wortlänge von 32 Bit einen 
Zahlenbereich [-2^^ = -2.147.483.648, 2^1 - 1 = 2.147.483.647]. 

Bei der Abbildung von nicht ganzzahligen Zahlen z geht man von der 
Darstellung in wissenschaftlicher Notation aus: z = m • ß®, wobei m die 
Mantisse sowie B die Basis des Zahlensystems bezeichnet. Beispiele hierfür 
sind: 

• 3,14159 = 0,314159 • 10^ = 0,314159E1 

• 0,000021 = 0,21 • IO""* = 0,21E-4 

In der so genannten Gleitkommadarstellung werden die Mantisse m (inkl. 
Vorzeichen) und der Exponent e (inkl. Vorzeichen) in einem festen Format 
abgespeichert (unter Verwendung einer festen Basis B). Beispielsweise kann 
man in einem Speicherwort von 4 Byte das Bit ganz links als Vorzeichen- 
bit der Mantisse, die nächsten 15 Bit für die Dualdarstellung der Mantisse, 
das nächste Bit als Vorzeichenbit des Exponenten und die restlichen 15 Bit 
für die Dualdarstellung des Exponenten verwenden. Die Länge der Mantisse 
bestimmt die darstellbare Genauigkeit, die Länge des Exponenten den dar- 
stellbaren Zahlenbereich. 

Die Darstellung textueller Informationen erfolgt im Rechner über eine zu 
definierende Zuordnung von Zeichen zu Bit-Mustern (d.h. Dualzahlen). Am 
gebräuchlichsten ist der ASCII-Code (American Standard Gode for Informa- 
tion Interchange, ISO 646), bei dem in der ursprünglichen Form sieben Bit 
verwendet werden (d. h. maximal 128 verschiedene Zeichen). Damit kann man 
beispielsweise in einem Megabyte Speicher bei Verwendung des ASGII-Godes 
mehr als 500 Schreibmaschinenseiten Text codieren, wenn man von ca. 30 
Zeilen x 60 Zeichen « 1800 Zeichen pro Schreibmaschinenseite ausgeht. Da 
der ASGII-Gode für die Vielzahl international gebräuchlicher Zeichen nicht 
ausreichend ist, wurden erweiterte Godes entwickelt. Einfache Lösungen sind 
länderspezifische Erweiterungen des ASGII-Godes auf acht Bit, wodurch et- 
wa deutsche Umlaute dargestellt werden können. Der weitergehende Unicode- 
Standard (ISO 10646) verwendet 16 bzw. 32 Bit, wodurch alle gebräuchlichen 
Zeichensätze abgebildet werden können. 

Für die Abbildung sonstiger Informationen (Graphiken, Bilder, Töne, Vi- 
deos u. A.) existieren eine Vielzahl von Standards bzw. Godierungsvorschrif- 
ten, die eine entsprechende Abbildung auf Bitmuster definieren. Gegebenen- 
falls ist zur digitalen Godierung kontinuierlicher Größen zunächst eine Dis- 
kretisierung durchzuführen, woraufhin aus solchen diskreten Daten dann die 
eigentliche digitale Darstellung berechnet wird. Beispiele hierfür sind: 

• analoge Audio-Daten, Diskretisierung über AD- Wandler (Analog-Digital- 
Wandler), Abspeicherung auf GD (Gompact Disc) 

• Bilddaten, Rasterung in diskrete Bildpunkte, Godierung als Bitmuster 

Zumeist kommt bei der Codierung negativer Zahlen dagegen aus rechentechni- 
schen Gründen die Komplementdarstellung zum Einsatz, auf die hier nicht näher 
eingegangen wird. 
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Abschließend ist festzuhalten, dass prinzipiell alles, was diskret messbar 
ist, auch verlustfrei binär codiert werden kann. 



2.3 Hardware 

Im ersten Abschnitt dieses Kapitels wurde Informatik als die Wissenschaft 
von der „Mechanisierung der Abstraktion“ charakterisiert. Im zweiten Ab- 
schnitt wurden verschiedene theoretische Modellierungen innerhalb dieses 
Rahmens angesprochen. Letztendlich basiert das Entstehen der Informatik 
darauf, dass seit der zweiten Hälfte des zwanzigsten Jahrhunderts eine effek- 
tive technische Umsetzung dieser Mechanisierung entwickelt wurde. 

Unter Hardware versteht man alle materiellen (technischen) Komponen- 
ten eines Rechnersystems. Hardware kann als praktische Konkretisierung ei- 
nes Maschinenmodells der Informatik angesehen werden. Sie dient als Ab- 
laufmechanismus für Algorithmen in Form von Software. Von den Maschi- 
nenmodellen der theoretischen Informatik unterscheidet sich die Computer- 
hardware in der Regel einerseits durch die größere Leistungsfähigkeit hin- 
sichtlich der abgebildeten Funktionsvielfalt (die für die meisten theoretischen 
Untersuchungen im Wesentlichen irrelevant ist), während konkrete Computer 
andererseits durch die Endlichkeit der Ressourcen (wie Speicherplatz) einge- 
schränkt sind. 

Unter Rechnerarchitektur versteht man die interne Struktur von Rech- 
nern, d. h. den Aufbau aus verschiedenen Komponenten und die Organisati- 
on von Arbeitsabläufen. Das auch heute noch weitgehend gültige prinzipielle 
Rechnerarchitekturmodell ist die klassische Von-Neumann- Architektur. Die- 
se wird in Abbildung 2.2 veranschaulicht und in den folgenden Abschnitten 
näher beschrieben.^® 



externe 

Speicher 




Datenausgabe 



Dateneingabe 



Abb. 2.2. Von-Neumann- Architektur 



15 



Zur Vertiefung vgl. z. B. Tanenbaum und Goodman (1999). 
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2.3.1 Prozessoren 

Das „Herz“ eines Computers bildet der Prozessor (Zentraleinheit, Central 
Processing Unit, CPU), der die Ausführung von Befehlen zur Aufgabe hat. 
Dies geschieht in einem bestimmten Takt. Die Taktfrequenz heute üblicher 
Prozessoren liegt im GHz-Bereich, wobei für die Ausführung von Instruktio- 
nen in der Regel mehrere Takte benötigt werden. Eine einfache, nur einge- 
schränkt aussagekräftige Leistungskennzahl von Prozessoren ist MIPS (Mil- 
lion Instructions Per Second); so besäße ein Prozessor mit einem Takt von 1 
GHz und einer durchschnittlichbenötigten Taktanzahl von zehn pro Instruk- 
tion die theoretische Kennzahl 100 MIPS.^® 

Die Leistungsfähigkeit von Prozessoren bzw. Rechnersystemen wird in der 
Praxis u. a. durch die Zeit zur Ausführung bestimmter Programme beurteilt 
{Benchmarks), da die Ausführungszeit verschiedener Instruktionen situati- 
onsabhängig ist. So ist z. B. die Ausführung einer Addition zweier Zahlen 
davon abhängig, ob diese Werte bereits in entsprechenden prozessorinternen 
Registern vorhanden sind (z.B. als Resultate vorhergehender Instruktionen) 
oder ob sie erst aus dem Hauptspeicher (einem CPU-externen aber rechner- 
internen Speicher zum schnellen Zugriff auf dort repräsentierte Programme 
bzw. Daten) geholt werden müssen. In der Regel kommuniziert ein Prozessor 
mit den anderen Komponenten eines Rechners über einen niedrigeren Takt 
als dem eigentlichen CPU-Takt. Diese Kommunikation findet über einen oder 
mehrere so genannte „Busse“ statt. Beispielsweise kommuniziert in einem 
heutigen „Standard-PC“ {Personal Computer) eine CPU mit einem Takt 
von z.B. 3,2 GHz über den „PCI-Bus“ {Peripheral Component Interconnect) 
z. B. mit einer erheblich niedrigeren Taktfrequenz (ca. 800 MHz) mit Erweite- 
rungskarten (Hardwarekomponenten, die über definierte Schnittstellen einen 
Rechner ergänzen). 

Ein Prozessor besteht hauptsächlich aus einem Steuerwerk und einem 
Rechenwerk. Das Steuerwerk regelt die Verarbeitung im Prozessor, im We- 
sentlichen durch das Einlesen der jeweils nächsten auszuführenden Instrukti- 
on (Operation, Befehl), während das eigentliche Ausführen von elementaren 
Berechnungen durch das Rec/ienwerfc geschieht. Der grundlegende Ablaufzyk- 

Man beachte, dass sich in der Vergangenheit die Rechenleistung entsprechend 
Moore’s Gesetz erhöht hat: Die Rechenleistung handelsüblicher Rechner verdop- 
pelt sich alle 18 Monate. Inwiefern dieses „Gesetz“ auch in der Zukunft seine 
Gültigkeit hat, kann nicht sicher beurteilt werden, da die stetige Steigerung der 
Taktfrequenz immer höhere technische Anforderungen an die Hardware stellt. 
Wir werden hier nicht auf die technische Realisierung über Schaltnetze, Tran- 
sistoren u. Ä. eingehen. Heutige Rechnerkomponenten sind durch eine sehr ho- 
he Integration entsprechender Basisbausteine gekennzeichnet (VLSI-Ghips, Very 
Large Scale Integration) . Ein Chip (z. B. Logikchip, Speicherchip) ist ein Bauteil, 
auf dem sehr viele Funktionselemente (Größenordnung: Millionen) auf relativ 
kleiner Fläche untergebracht sind. Dabei kommen insbesondere entsprechende 
Halbleiterbausteine aus Silizium zum Einsatz. Die Integrationsdichte von Chips 
wächst kontinuierlich (auch wenn aus physikalischer Sicht ein Ende absehbar ist). 
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lus stellt sich wie folgt dar: Das Steuerwerk holt und interpretiert die nächste 
Instruktion und hierfür benötigte Daten aus dem Hauptspeicher; die Instruk- 
tion wird gegebenenfalls durch das Rechenwerk ausgeführt und, falls nötig, 
werden Resultate in den Hauptspeicher (zurück-)geschrieben. Ein Prozessor 
besitzt in der Regel mehrere spezifische Register, die etwa Zwischenergebnis- 
se von Operationen aufnehmen können und dabei insbesondere der Ablauf- 
beschleunigung dienen. Durch andere Register wird z.B. abgebildet, welche 
Instruktion als Nächstes auszuführen ist (Befehlszähler) oder wie sich der 
aktuelle Status darstellt. Prozessoren besitzen weiterhin typischerweise eini- 
ge spezialisierte Funktionselemente wie z.B. einen Baustein zur effizienten 
Berechnung von Operationen mit Gleitkommazahlen. 

Man kann Prozessoren hinsichtlich der Art bzw. Menge der Instruktionen, 
die sie ausführen können, unterscheiden. Teilweise wird in CISC-Prozessoren 
(CISC: Complex Instruction Set Computer) und RISC-Prozessoren (RISC: 
Reduced Instruction Set Computer) unterschieden. Während der Aufbau von 
Ersteren durch einen komplexen Instruktionsvorrat (bis zu mehreren hundert 
verschiedenen Instruktionen) relativ kompliziert ist, ergeben sich bei RISC- 
Prozessoren durch den eingeschränkten Instruktionsvorrat Vorteile hinsicht- 
lich eines einfacheren Aufbaues und damit gegebenenfalls auch möglichen 
höheren Taktfrequenzen. Beispiele für CISC-Prozessoren sind die Pentium- 
Prozessoren von Intel. 

2.3.2 Interner Speicher 

Im internen Speicher (Hauptspeicher, Primärspeicher) eines Rechners wer- 
den sowohl Daten als auch Programme verwaltet. Hierbei geht man von ei- 
nem so genannten linearen Adressraum aus. Das heißt, der Hauptspeicher 
besteht aus einer Sequenz (beginnend mit 0) durchnummerierter Speicher- 
zellen, die jeweils ein Byte aufnehmen können. Die Interpretation der Daten 
(oder Programme) im Hauptspeicher basiert auf entsprechenden Codierungs- 
bzw. Interpretationsvorschriften; vgl. Abschnitt 2.2. 

Gebräuchliche Größen für den Hauptspeicher eines Rechners sind 128 MB 
bis zu mehreren Gigabyte. Durch die so genannte virtuelle Speicherverwal- 
tung (Paging) ist der den Anwendungen zur Verfügung stehende Adressraum 
heute in der Regel unabhängig vom physisch vorhandenen Speicher. Die Idee 
dieser Technik besteht darin, dass dann, wenn kein realer physischer Spei- 
cher mehr zur Verfügung steht, ein Speicherbereich der benötigten Größe 
gesucht wird, dessen Inhalt aktuell anscheinend nicht verwendet wird und 
somit auf externe Speicher ausgelagert werden kann. Anschließend kann der 
Inhalt dieses Speicherbereiches mit aktuell benötigten Daten und Anweisun- 
gen überschrieben werden. 

Man unterscheidet Speicher in RAM {Random Access Memory, Speicher 
mit wahlfreiem Lese- und Schreibzugriff) und ROM {Read Only Memory). 
Unter einem Cache versteht man einen relativ schnellen (und somit ge- 
gebenenfalls teureren) Zwischenspeicher, der die Kommunikation zwischen 
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entsprechenden Komponenten (z. B. zwischen Prozessor und Hauptspeicher) 
durch eine Pufferung beschleunigen soll. Typische Zugriffszeiten (Zeit zum 
Lesen des Inhaltes einer Speicherzelle) für aktuelle Speicherchips liegen im 
Bereich von Nanosekunden (10“®). 

2.3.3 Externe Speicher 

Da der Hauptspeicher in der Regel flüchtig (d.h. zur Aufrechterhaltung der 
Inhalte der Speicherzellen ist eine dauerhafte Betriebsspannung nötig) und 
in seiner Größe beschränkt ist, bedarf es zusätzlich externer Speicher (Se- 
kundärspeicher), die große Datenmengen dauerhaft speichern. Hierzu wer- 
den im Wesentlichen Magnetplatten (Festplatten) verwendet, bei denen die 
Daten auf einem in Sektoren und Spuren aufgeteilten Plattenstapel über 
einen radial positionierbaren Schreib-/Lesekopf gespeichert werden. Gängige 
Größen liegen im zwei- und dreistelligen Gigabyte-Bereich; die Zugriffszeiten 
liegen in der Größenordnung von Millisekunden (10“^). Zur transportablen 
Speicherung kommen neben der nur noch selten verwendeten klassischen 3,5- 
Zoll-Diskette mit einer Kapazität von 1,44 MB inzwischen verschiedenste Me- 
dientypen mit Kapazitäten von ca. 100 MB bis zu mehreren GB zum Einsatz, 
wie z.B. USB-Sticks (USB: Universal Serial Bus) oder diverse Speicherkar- 
ten. Schließlich kommen insbesondere zur Datensicherung Magnetbänder zum 
Einsatz, auf denen große Datenmengen kostengünstig und dauerhaft gespei- 
chert werden können; Nachteil ist der relativ langsame sequenzielle Zugriff. 

Inzwischen haben sich neben magnetischen Medien vermehrt optische Me- 
dien durchsetzen können. Entsprechende „Standards“, die das klassische GD- 
Format sowohl hinsichtlich Kapazität als auch hinsichtlich Wiederbeschreib- 
barkeit verbessern, gibt es in einer gewissen Vielfalt (GD-R: Gompact Disc - 
Recordable, GD-RW: Gompact Disc - Rewritable, DVD: Digital Versatile 
Disc). 

2.3.4 Peripheriegeräte 

Peripheriegeräte bilden die Schnittstelle eines Rechnersystems nach außen. 
Dies kann sich einerseits auf externe technische Systeme beziehen (z. B. ei- 
ne Werkzeugmaschine oder ein Barcodelesegerät). Andererseits wird hiermit 
insbesondere auch die so genannte Mensch-Maschine-Schnittsteile abgebil- 
det. Hierbei ist auf die Bedeutung einer ergonomischen Gestaltung dieser 
Geräte hinzuweisen. Ausgehend von dem klassischen Grundprinzip der elekt- 
ronischen Datenverarbeitung (Eingabe - Verarbeitung - Ausgabe, EVA) un- 
terscheidet man dabei in Eingabe- und Ausgabeperipherie. Zur Eingabepe- 
ripherie zählt man z. B. Tastatur, Maus, Touchpanel/Touchscreen, Joystick, 
Scanner, Mikrofon, Kamera, Datenhandschuh usw. Zur Ausgabeperipherie 
zählt man z. B. Bildschirm, Lautsprecher, Drucker, 3D-Brille usw. Bei moder- 
nen Entwicklungen ist die eindeutige Unterscheidung in Eingabe- und Aus- 
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gabeperipherie teilweise nicht mehr möglich. Beispiele hierfür sind Joysticks 
mit Rückkopplung oder eine 3D-Brille mit Pupillenabtastung. 

Bei externen technischen Geräten finden derzeit verstärkt Transponder 
Anwendung, wobei insbesondere die RFID-Technik {Radio Frequency Iden- 
tification genutzt wird. Diese Technik kann verwendet werden, um beliebi- 
ge Signale per drahtlosem Funk an einen Rechner zu übermitteln, z. B. zur 
Identifizierung oder zur Übertragung von weiteren Daten des Transponder- 
Trägers. Dazu wird der RFID-Transponder an einem Gegenstand (wie ei- 
nem zu transportierenden Gontainer) befestigt. Zusätzlich wird eine Sende- 
Empfangs-Einheit benötigt, die mit dem Transponder kommuniziert und 
gleichzeitig mit dem Rechner verbunden ist. RFID-Transponder können in 
Form von Etiketten, Anhängern oder auch Ghipkarten auftreten, wodurch 
eine große Bandbreite an Anwendungsmöglichkeiten (von der Gontaineriden- 
tifizierung bis zur Zutrittskontrolle) entsteht. 



2.4 Software 

Unter Software versteht man Programme, die auf der Hardware eines Rech- 
nersystems ausgeführt werden. Auf die eigentliche Softwareentwicklung wird 
in Kapitel 6 eingegangen. 

Man kann Software in Systemsoftware und Anwendungssoftware klassifi- 
zieren. Während Systemsoftware die Grundlage zur Verwendung von Rech- 
nersystemen darstellt, wird durch die Anwendungssoftware in der Regel die 
von dem Nutzer benötigte spezifische Funktionalität bereit gestellt. Zur Sys- 
temsoftware zählt man insbesondere Betriebssysteme, Übersetzer (Gompi- 
ler/Interpreter), sowie Softwarewerkzeuge, die die Entwicklung von Software 
und die Verwaltung von Systemen unterstützen. 

2.4.1 Betriebssysteme 

Die Notwendigkeit von Betriebssystemen ergibt sich daraus, dass Hardware 
nicht direkt auf einfachem Wege nutzbar ist. Betriebssysteme verwalten die 
Ressourcen von Rechnern und schirmen den Programmierer und Anwender 
von den Rechnerspezifika ab, indem sie ihm über gewisse Schnittstellen Zu- 
griff auf entsprechende Funktionalitäten bereitstellen. Beispielsweise existiert 
typischerweise eine Operation, mit der man Dateien auf einer Festplatte ko- 
pieren kann, ohne etwas über den Aufbau und die Dateiorganisation auf die- 
sem externen Speicher zu wissen. 

Ganz allgemein zeichnet sich die Informatik dadurch aus, dass ihre Unter- 
suchungsgegenstände häufig auf verschiedenen Abstraktionsstufen betrach- 
tet werden, um die Komplexität entsprechender Strukturen zu bewältigen.^® 

Beispielsweise kann man das Abspeichern eines Variablenwertes im Hauptspei- 
cher auch aus dem Blickwinkel eines Hardwaretechnikers betrachten, der die zu 
Grunde liegenden elektronischen Abläufe untersucht. 




2.4 Software 



31 



Oftmals ergibt sich dabei eine hierarchische Schichtung in mehrere aufeinan- 
der aufbauende Ebenen. Hiermit hängt das Konzept der Virtualisierung eng 
zusammen. Durch bestimmte Techniken wird dem „Nutzer“ (der auch eine 
Software- oder Hardwarekomponente sein kann) eine abstrakte Sicht auf ein 
System bzw. eine Systemkomponente zur Verfügung gestellt. Beispielsweise 
schirmt ein Betriebssystem den Anwender von der realen Komplexität der 
Hardware durch Bereitstellung einer „abstrakten virtuellen Maschine“ ab. So 
mag ein Betriebssystem auf verschiedenen Hardwareplattformen verfügbar 
sein, wodurch die Nutzung unabhängig von spezifischen Hardwareeigenschaf- 
ten wird. Häufig führt eine solche Virtualisierung zu einem geschichteten Sys- 
tem, bei dem jede Schicht eine zunehmend abstraktere Funktionalität erfüllt; 
vgl. die Diskussion der Schichtenarchitektur bei Kommunikationsprotokollen 
in Abschnitt 2.5.2. Die interne Realisierung dieser Funktionalitäten ist zu ih- 
rer Nutzung im Wesentlichen irrelevant - relevant ist primär die Schnittstelle, 
über die entsprechende Funktionalitäten genutzt werden können. 

Die wesentlichen Ressourcen, die vom Betriebssystem verwaltet werden, 
sind: 

• Prozessor(en) ^ Prozessverwaltung, Zuteilung von Prozessorzeit 

• Hauptspeicher ^ Zuteilung und Verwaltung von Hauptspeicherplatz 

• Externe Speicher ^ Zugriffe auf Dateien und Verzeichnisse 

• Ein-/ Ausgabe — > Durchführung von Ein- und Ausgabevorgängen von bzw. 
zu Peripheriegeräten 

Im Zusammenhang mit Betriebssystemen ist ein Prozess als ein in 
Ausführung befindliches Programm definiert. Beispielsweise können durch- 
aus mehrere Prozesse eines Textverarbeitungsprogramms simultan ausgeführt 
werden, die dann gegebenenfalls vollständig unabhängig voneinander sind 
(z. B. unabhängige Adressräume). 

Im Folgenden werden einige Möglichkeiten moderner Betriebssysteme an- 
gesprochen. Multitasking-Betriebssysteme ermöglichen die „scheibchenweise“ 
Ausführung von mehreren Prozessen, wodurch für den Nutzer der Eindruck 
der Parallelausführung verschiedener Prozesse entsteht. Weiterhin bieten mo- 
derne Betriebssysteme durch eine virtuelle Speicherverwaltung einen linearen 
Adressraum für Anwendungen, der unabhängig von der Größe des physischen 
Speichers ist; vgl. S. 28. In modernen Betriebssystemen sind darüber hin- 
aus insbesondere eine Netzwerkintegration (einfacher Zugriff auf nicht lokale 
Ressourcen) als auch entsprechende Sicherheitskonzepte (Beschränkung des 
Zugriffes auf Ressourcen durch eine feinkörnige Rechtezuordnung) realisiert. 

Im Weiteren werden einige neuere Entwicklungen im Betriebssystembe- 
reich kurz erläutert: 

• Über das bereits weit verbreitete Multithreading ist es möglich, ver- 
schiedene „Ausführungseinheiten“ (Threads) innerhalb eines Prozesses 
parallel ablaufen zu lassen. Beispielsweise könnten die simultane Recht- 
schreibüberprüfung und die Druckfunktion innerhalb einer Textverarbei- 
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tung als Threads realisiert sein. Durch den quasi gemeinsamen Zugriff auf 
dieselben Daten ergeben sich Synchronisationsprobleme, die gelöst werden 
müssen. 

• Da die Leistungsfähigkeit von Prozessoren in absehbarer Zeit an physika- 
lische Grenzen stoßen wird, sofern nicht grundsätzlich neue Technologien 
entwickelt werden, kann dann eine weitere Steigerung der Rechenkapa- 
zitäten nur durch die parallele Ausführung auf mehreren Prozessoren 
erreicht werden. Hierzu gibt es verschiedene Konzepte dahingehend, 
welche Komponenten vervielfältigt werden: Komponenten innerhalb von 
Prozessoren, Prozessoren, Prozessoren und Speicher, ganze Computer 
usw. Hierbei ergeben sich ebenfalls vielfältige Synchronisationsprobleme. 

• Schließlich werden sich die Betriebssysteme auch hinsichtlich der Benut- 
zerfreundlichkeit weiterentwickeln. Hierzu gehören nicht nur die einfachere 
Bedienbarkeit durch eine verbesserte graphische Benutzeroberfläche, son- 
dern auch Konzepte wie die verteilter Betriebssysteme, bei denen die Nut- 
zung lokaler und verteilter Ressourcen für den Nutzer homogen verläuft. 
Beispielsweise sollte es für einen Anwender innerhalb eines Unternehmens 
keine Rolle spielen, an welchem Computer er arbeitet. Ziel ist es hierbei, 
dem Nutzer an einem beliebigen Arbeitsplatz immer die gleiche Arbeits- 
umgebung zu bieten. 

Die am weitesten verbreiteten Betriebssysteme sind die verschiedenen Va- 
rianten von Microsoft Windows einerseits sowie Unix- Varianten wie z.B. Li- 
nux andererseits. 

2.4.2 Programmierung 

Unter einer Programmiersprache versteht man eine formale Sprache, mit der 
Software entwickelt werden kann. Es existiert eine gebräuchliche Einteilung 
von Programmiersprachen in verschiedene Generationen. 

Unter Programmiersprachen der 1. Generation versteht man Maschinen- 
sprachen, die direkt dem Instruktionssatz der jeweiligen Prozessoren entspre- 
chen. Solche Programme sind damit direkt auf der entsprechenden Hard- 
ware ausführbar, was eine optimale Ausnutzung der Hardwareressourcen 
ermöglicht. Der allgemeine Aufbau eines Befehles in einer Maschinensprache 
kann als Operation Operand beschrieben werden. Beispielsweise mag der 
Befehl B3 4A die Instruktion zum Laden eines bestimmten Prozessorregisters 
mit dem Inhalt der Speicherzelle an Position 4A bedeuten. Maschinensprachen 
werden heute im Wesentlichen nur noch zur Programmierung von Mikrochips 
mit kleinen Programmen direkt verwendet. Da Maschinenspracheprogramme 
sehr schwer lesbar sind, ist die Programmierung aufwändig und fehleranfällig 
bzw. sind die entsprechenden Programme schwer zu warten. 
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Unter Programmiersprachen der 2. Generation versteht man Assembler- 
sprachen, die auf demselben Programmiermodell wie die Maschinensprachen 
basieren. Die reale Programmierung wird aber durch dem Menschen entge- 
genkommende Vereinfachungen unterstützt. So werden die Befehle nicht mehr 
als Zahlencodes, sondern in Form von mnemotechnischen Abkürzungen ver- 
wendet . Weiterhin kann der Programmierer etwa symbolische Speicheradres- 
sen definieren und nutzen. So könnte die obige Operation als LDA betrag 
codierbar sein (Laden eines Registers mit dem Inhalt der Speicherzelle, die 
mit betrag benannt ist). Hieraus ergibt sich insbesondere eine verbesserte 
Verständlichkeit der Programme. Allerdings benötigt man ein entsprechen- 
des Übersetzungsprogramm (Assembler), mit dem Assemblerprogramme in 
Maschinencode umgewandelt werden. Trotzdem bleibt die Programmierung 
in Assemblersprachen mühsam; weiterhin sind entsprechende Programme in 
der Regel nicht portabel (d. h. sie sind ohne größere Veränderungen nicht auf 
einer anderen Hardware ausführbar). 

Bei den so genannten prozeduralen Programmiersprachen der 3. Genera- 
tion geschieht die Codierung von Programmen in problemorientierter und 
weitgehend maschinenunabhängiger Form. Damit sind Programme bei Ein- 
haltung gewisser Standards auf mehreren Rechnertypen lauffähig (portabel) . 
Zur Transformation in die entsprechenden Maschinensprachen sind Überset- 
zungsprogramme nötig (Compiler/Interpreter). Klassische Beispiele für Pro- 
grammiersprachen der 3. Generation sind Pascal, C, Cobol, Fortran und Mo- 
dula. Bei einer „guten“ Programmierung mit solchen Programmiersprachen 
ist die Verständlichkeit nicht zu umfangreicher Programme in der Regel rela- 
tiv einfach. Als dem entgegenstehendes Beispiel sei das in Abbildung 2.3 dar- 
gestellte syntaktisch korrekte C-Programm^® angeführt, dessen Zweck man 
nur aufgrund eines außergewöhnlichen Layouts vermuten kann. 

Zielsetzung der so genannten Strukturierten Programmierung ist es, dass 
der Programmcode die Lösung der Problemstellung auf einfache Art wider- 
spiegelt. Mittel hierzu sind der modulare Aufbau von Programmen (z.B. 
durch Verwendung von Unterprozeduren und Funktionen), die Verwendung 
strukturierter Datentypen, die Verwendung von „sprechenden“ Variablenna- 
men, die strukturierte Nutzung der Basiskonstrukte zur Definition von Algo- 
rithmen (Sequenz, bedingte Anweisung, bedingte Iteration) usw. Beispiels- 
weise sollte die Funktionsweise des in Abbildung 2.4 dargestellten Pascal- 
Programms relativ offensichtlich sein. 

Der Ansatz der Strukturierten Programmierung ist relativ erfolgreich bei 
der „Programmierung im Kleinen“. Problematisch bleibt aber weiterhin die 
Durchführung großer Programmierprojekte mit vielen Programmierern und 
Zielsystemen mit mehreren Millionen Codezeilen. Dementsprechend wurden 
hierfür neue Methoden und Techniken entwickelt; vgl. Kapitel 6. 

Ausgezeichnet beim 12th International Obfuscated C Code Contest (1995); vgl. 

http : / /www . de . ioccc . org. 
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#include <stdio.h> 

#define 1111 OxFFFF 
#define 111 for 
#define 11111 if 
#define 1111 unsigned 
#define 1111 struct 
#define 11111 short 
#define 11111 long 
#define 11111 putchar 

#define 11111(1) l=malloc(sizeof (1111 11111) ); 1->11111=1-1 ; 1->11111=1-1 ; 
#define 11111 *11111++=1111%10000;1111/=10000; 

#define 11111 11111 (! 11->11111) ■ailll(ll->lllll) ; 11->11111->11111=11 ; }\ 
11111 =( 11 = 11 -> 11111 ) -> 111 ; 11 = 1 - 1 ; 

#define 1111 1000 







1111 11111 -c 
1111 11111 * 


11111, *11111 


;1111 


11111 111 [ 


1111] ; )■ ;main 


O-Cllll 11111 


*1111, *111,* 


11, *1111, * malloc ( ) ; 1111 


11111 1111 ; 


11111 111,11 ,1; 


1111 11111 *1111,* 


11111; 111(1 


=1-1 ;1< 14; lllll("\t\"8)>l\"9! .)>vl" 


[l]‘’LO,++l 


) ;scanf ("%d",&D ; 11111 (111) 11111(1111 


) (ll=lll)-> 


111[111->111[1-1] 


=1]=1111;111(111 


=1+1;11K=1; 


++lll)-ai=llll; 


1111 = (1111=( 


llll=lll))-> 


111; 11111 =( 


111=11)->111; 


11=(1111=1-1 


) ;lll(;llll-> 


111111 11111!= 


*1111;){1111 


+=111**1111++ 


;11111 11111 


(++11>1111){ 


11111 1111=( 


1111 =llll-> 


11111)->111; 


}}111(;1111; 


)-aiiii 11111 


(++11>=1111) 


{ 11111} } * 


11111=1111;} 




111(1=(11=1- 


1) ; (1<1111)&& 




(11->111[ 1] 


1=1111) ;++l) ; 


111 (;11;11= 


11->11111,1= 


lllD-CllK— 1 


;1>=1-1;— 1, 


++ll)printf ( 


(11)? ((117.19) 


"0 

o 

P- 

II 


19,’'\nZ04d") 


) :"7,4d",ll-> 


111 [1] ) ; } 
11111(10); } 



Abb. 2.3. Beispiel eines unstrukturierten Programms in C 



Als Programmiersprachen der 4. Generation („4GL-Sprachen“ - Forth 
Generation Language) bezeichnet man Ansätze, bei denen der Programmie- 
rer nicht mehr jeden einzelnen Schritt der Problemlösung vorgeben muss, 
sondern nur über eine entsprechende Spezifikation anzugeben hat, was gelöst 
werden soll (nicht mehr wie). Deshalb nennt man solche Programmierspra- 
chen auch deskriptiv oder deklarativ. Diese Ansätze sind aber in der Regel 
auf eingeschränkte Problembereiche begrenzt, für die entsprechende spezielle 
Sprachen und unterstützende Softwarewerkzeuge entwickelt werden können. 
Herausragendes Beispiel ist die Entwicklung von Datenbankanwendungen: 
Zum einen existieren hierfür entsprechende angepasste Software-Entwick- 
lungsumgebungen, zum anderen existiert zur Abfrage von Daten aus relatio- 
nalen Datenbanken eine standardisierte Abfragesprache, bei der der Benutzer 
das Wissen über die eigentlichen prozeduralen Abläufe nicht mehr benötigt; 
vgl. Kapitel 5. Ziel der Datenbankabfrage sei die Suche nach den Namen aller 
Studierenden in einer Universitätsdatenbank, die das Fach „Informationsma- 
nagement“ (IM) als erstes Vertiefungsfach belegt haben. Ein prozeduraler 
Pseudo-Gode hierfür sähe folgendermaßen aus: 
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PRQGRAM Fakultaet; 

(* Programm zur Berechnung der Fakultaet einer positiven *) 
(* ganzen Zahl im Bereich von 0 bis 16 *) 

(* Autor: Eddi Schulz, 2.11.2000 *) 

VAR eingabe: INTEGER; 

FUNCTION fak(n: INTEGER) : INTEGER; 

BEGIN 

IF (n = 0) THEN 
fak := 1 
ELSE 

fak := n * fak(n-l) ; 

END; 

BEGIN 

WRITEC’ Eingabe: ’); 

READLNC eingabe) ; 

WRITELNC 'Fakultaet von eingabe, ’ = ’, fak (eingabe) ) ; 
END. 

Abb. 2.4. Beispiel eines strukturierten Programms in Pascal 



Öffne Datenbcüik Studierende 

Solange ein nächster Eintrag existiert: 

Hole diesen Eintrag 

Prüfe, ob im Feld Vertiefungsf achl der Eintrag IM steht 
Wenn ja, datnn: 

Drucke den gesamten Namen des aktuellen Eintrages 

Als Abfrage in SQL {Structured Query Language; vgl. Abschnitt 5.4) verein- 
facht sich dies zu: 

SELECT name FRDM Studierende WHERE Vertiefungsf achl = "IM"; 

Diese Abfrage wird automatisch in eine Operationsfolge ähnlich des oben ste- 
henden Pseudo-Codes übersetzt. Zielsetzung des Einsatzes von 4GL-Sprachen 
ist neben einer Produktivitätserhöhung auch die Ermöglichung der Program- 
mierung solcher Abfragen durch „einfache Anwender“. Allerdings ist die 
Komplexität realistischer Datenbankabfragen in der Regel zu hoch bzw. das 
Erfordernis nach einem Verständnis des unterliegenden Datenmodells unrea- 
listisch, als dass ein solcher Ansatz hierfür hinreichend wäre. 

Der Einsatzbereich der so genannten wissensbasierten (logischen, deduk- 
tiven) Programmiersprachen (teilweise auch als Programmiersprachen der 5. 
Generation bezeichnet) beschränkt sich primär auf Gebiete, in denen „Wis- 
sen“ im Sinne der Aussagenlogik soweit formalisiert werden kann, dass hier- 
mit die Lösung entsprechender Problemstellungen ermöglicht wird. Beispiels- 
weise gibt es Versuche, die Diagnose von Krankheiten durch eine entsprechen- 
de Wissensbasis, die Merkmale und Kausalzusammenhänge in diesem Bereich 
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als Fakten und Regeln abbildet, zu unterstützen. Hieraus soll durch eine 
schlussfolgernde „Inferenzmaschine“ und eine entsprechende Benutzerschnitt- 
stelle ein „Experte“ auf diesem Gebiet nachgebildet werden, der unter An- 
gabe entsprechender Daten deduktiv Krankheiten diagnostizieren kann. Die 
Hoffnungen in solche Expertensysteme, wie auch in andere Ansätze des For- 
schungsgebietes Künstliche Intelligenz (KI, AI: Artificial Intelligence), sind 
aber in der Vergangenheit nicht immer erfüllt worden. Das bekannteste Bei- 
spiel für eine logische Programmiersprache ist Prolog. 

Ein weiteres Denkmodell, das das Programmieren auf eine höhere (ab- 
straktere) Stufe stellen soll, ist der funktionale Ansatz. Dabei wird grundle- 
gend auf dem mathematischen Funktionsbegriff aufgebaut. Uber eine Verket- 
tung und Rekursion können hiermit Algorithmen abgebildet werden. Funk- 
tionale Programmiersprachen (wie LISP, Haskell) haben sich aber im We- 
sentlichen nur für bestimmte Problembereiche durchsetzen können. 

Schließlich sei noch kurz auf objektorientierte Programmiersprachen ein- 
gegangen. Beispiele für objektorientierte Programmiersprachen sind Small- 
talk, C-|— I-, Java, VB.NET, C#, Eiffel und Beta. Während im algorithmi- 
schen Denkmodell der Sprachen der 3. Generation Operationen und Daten 
getrennt sind, basiert das objektorientierte Paradigma auf der Kapselung von 
Daten und zugehörigen Operationen in Objekten. Hierbei kann ein Objekt 
als ein Ding oder eine Abstraktion mit (in gewissem Maße) definierten Gren- 
zen und einer Bedeutung für einen betrachteten Problembereich definiert 
werden. Gleichartige Objekte werden zu Klassen (Objekttypen) zusammen- 
gefasst. Diese Klassenbildung dient sowohl dem Problemverständnis als auch 
als Basis für eine (gegebenenfalls wiederverwendbare) Implementierung. Ein 
Objekt einer Klasse besitzt eine Identität, Eigenschaften (Attribute) und ein 
Verhalten (Methoden). Ein Beispiel für eine Klasse in einer Unternehmens- 
anwendung wäre KUNDE mit Eigenschaften wie z.B. Name, Adresse und 
Kreditstatus sowie Methoden wie z. B. „Adressänderung“ oder „Änderung 
Kreditstatus“. 

Neben der Kapselung von diesen Eigenschaften und Operationen in der 
Klasse KUNDE zeichnet sich das objektorientierte Paradigma durch das Kon- 
strukt Vererbung aus: Beispielsweise mag es angebracht sein, zwischen Privat- 
kunden und Großkunden zu unterscheiden, obwohl beide Objekttypen viele 
gemeinsame Eigenschaften und Operationen besitzen. Damit ist es sinnvoll, 
auf einer Konzipierung und eventuell einer Implementierung einer allgemei- 
nen Klasse KUNDE aufzubauen und hieraus eine Typhierarchie abzuleiten, 
in der spezielle Typen einschließlich der entsprechenden Eigenschaften und 
Operationen abgebildet werden. Auf die Objektorientierung wird in den Ab- 
schnitten 4.5 und 6.4.1 näher eingegangen. 

Im Hinblick auf die Notwendigkeit von Mechanismen zur (möglichst ein- 
fachen und flexiblen) Kombination von Softwarekomponenten wurden so ge- 
nannte Skript-Programmiersprachen entwickelt. Ein entsprechendes Scrip- 
ting implementiert insbesondere die prozedural orientierte Verbindung von 
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Komponenten zu fertigen Anwendungssystemen; vgl. Nierstrasz und Lum- 
pe (1997). Beispiele für Skript-Programmiersprachen sind Perl, Python und 
JavaScript. 

2.4.3 Softwarewerkzeuge 

Zur Transformation von Programmen einer höheren Programmiersprache 
in ausführbaren Maschinencode werden Übersetzungsprogramme {Compi- 
ler/Interpreter) benötigt. In der Regel ist der Ablauf beim Übersetzen in 
etwa der folgende: Zunächst wird der Quelltext auf syntaktische (und ein- 
fache semantische) Fehler überprüft, dann werden die einzelnen Programm- 
Module separat in entsprechende Maschinencode-Module übersetzt, die dann 
in einem weiteren Schritt verbunden werden {Linking). Im Gegensatz zu ei- 
nem Compiler übersetzt ein Interpreter jeden Schritt des Quelltextes erst 
bei der Ausführung, was einen entsprechenden Effizienzverlust verursacht. 
Für manche Programmiersprachen existieren sowohl Compiler als auch In- 
terpreter. Die Programmiersprache Java stellt einen weiteren Sonderfall dar: 
Durch einen Compiler wird zunächst ein maschinenunabhängiger (und damit 
portabler) „Byte-Code“ erzeugt, der dann von einer Ablaufumgebung inter- 
pretativ ausgeführt wird (zur Beschleunigung aber auch in einer weiteren 
Stufe in Maschinencode übersetzt werden kann). 

Weiterhin existieren Softwarewerkzeuge insbesondere für systemorientier- 
te, häufig wiederkehrende, anwendungsneutrale Aufgaben. Beispiele hierfür 
sind Editoren und Dienstprogramme zur Systemverwaltung. Die Trennung 
zwischen solchen Softwarewerkzeugen und Betriebssystemen ist teilweise 
fließend. Dies gilt ebenfalls für Benutzeroberflächen. Während die Windows- 
Betriebssysteme von Microsoft inhärent eine einfach bedienbare graphische 
Benutzeroberfläche besitzen, zählt man im Unix-Bereich teilweise selbst ei- 
ne Kommandozeilenoberfläche nicht zum eigentlichen Betriebssystem hinzu. 
Nachteil einer Kommandozeilenoberfläche, bei der die Befehle per Tastatur 
eingegeben werden müssen, ist die beim Anwender notwendige Kenntnis der 
Befehlssyntax. Graphische Benutzeroberflächen (mit Fenstern, Menüs, Leis- 
ten usw.) sind für den „normalen“ Anwender einfacher bedienbar, besitzen 
aber in der Regel eine geringere Flexibilität. Für den Bereich der Unix- 
Betriebssysteme existieren verschiedene „Betriebssystemaufsätze“, die das 
System um eine graphische Benutzeroberfläche erweitern. 

2.4.4 Anwendungssoftware 

Anwendungssoftware umfasst die Funktionalität, wofür der Anwender ein 
Rechnersystem im Grunde nutzt; alles andere ist eigentlich nur Mittel zum 
Zweck. Man unterscheidet hierbei Individualsoftware, die für eine spezielle 
Anwendungssituation eigens entwickelt wird, und Standardsoftware, die in 
einem gewissen Maße allgemeingültig ist und auf eine mehrfache Nutzung 
ausgerichtet ist (gegebenenfalls nach einer entsprechenden Anpassung). 




38 



2. Informatik und Informations- und Kommunikationstechnik 



Praktisch universell verbreitet sind heute funktionsübergreifende Stan- 
dardsoftwarepakete für Textverarbeitung, Tabellenkalkulation, Graphikbear- 
beitung sowie eventuell einfache Datenverwaltung [Office- P akete) . Dem ent- 
gegen steht funktionsbezogene Standardsoftware wie z. B. eine Buchhaltungs- 
software. 

Da die Erfordernisse für betriebswirtschaftliche Anwendungssysteme in 
einem gewissen Maße ähnlich sind, ist heute in Unternehmen eine zunehmen- 
de Dominanz von (betriebswirtschaftlicher) Standardsoftware zu verzeich- 
nen (z.B. SAP R/3 bzw. mySAP). Da jedoch in der konkreten Ausgestal- 
tung in der Regel unternehmensspezifische Besonderheiten zu beachten sind, 
ergibt sich in der Praxis zumeist der Zwang zu einer aufwändigen Anpas- 
sung bzw. Konfiguration von integrierten Standardsoftwaresystemen [Custo- 
mizing). Auf Anwendungssoftware wird in Kapitel 7 näher eingegangen. 



2.5 Rechnernetze 

Anfang der 1990er Jahre wurde im US-amerikanischen Wahlkampf der Be- 
griff Information (Super-) Highway populär. Die in diesem Begriff enthaltene 
Analogie zum Fernstraßennetz in den USA sollte die Potenziale eines globalen 
Rechnernetzes vermitteln. Die Frage nach entsprechenden Potenzialen bzw. 
Auswirkungen ist schwierig zu beantworten, was an dem folgenden Beispiel 
verdeutlicht werden kann: 

„Die Folgen einer Anlage, [. . .] welche Erleichterung, Beschleunigung, 
Sicherheit und Wohlfeilheit der Communication und des Verkehrs 
bezweckt, und daher auf Handel und Ackerbau, auf Manufacturen 
und Fabriken, auf den Werth der Gründe und Gapitalien, und über- 
haupt auf die wichtigsten materiellen Interessen der Gesellschaft un- 
mittelbar Einfluß hat, zum voraus und mit völliger Zuverlässigkeit 
angeben und berechnen zu wollen, ist sicher eine schwierige Aufgabe 
[...]“ (o.V. (1832), S. 86) 

Dieses Zitat aus dem Jahr 1832 steht im Zusammenhang mit dem Bau der ers- 
ten deutschen Staatseisenbahn von Braunschweig nach Wolfenbüttel (Eröff- 
nung 1.12.1838). Hieraus ergaben sich schließlich vielfältige Auswirkungen. 
Unter anderem entwickelten sich Eisenbahnwerkstätten und Signalindustrie 
in der Region; externe Effekte förderten die Braunkohle, Zuckerindustrie und 
den Tourismus. Dagegen wurden die Oker-Flößer im Wesentlichen substi- 
tuiert. Die Eisenbahnstrecke trug damit in der Region wesentlich zu einem 
wirtschaftlichen Wachstum und einem verstärkten Bevölkerungswachstum im 
19. Jahrhundert bei. 

Analog hierzu hat auch die Verwirklichung der Vision vom Information 
Highway vielfältige Auswirkungen. Heute wird häufig davon gesprochen, dass 
wir am Anfang der Informationsgesellschaft stehen. Der Produktionsfaktor 
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Information wird immer wichtiger; Informationen werden weitgehend un- 
abhängig von Raum und Zeit verfügbar. Man erhofft sich positive Auswirkun- 
gen wie neue Märkte, nachhaltiges Wachstum, Impulse für den Arbeitsmarkt, 
(nationale) Wettbewerbsvorteile, Ausgleich von Standortnachteilen, verbes- 
serte Lebensqualität usw. 

Unter dem Information Highway kann man eine globale, digitale, breit- 
bandige Kommunikationsinfrastruktur für einen offenen Verbund von mul- 
timedialen Endgeräten und leistungsfähigen Servern verstehen. In den USA 
entwickelte sich Anfang der 1990er Jahre eine politische Initiative mit dem 
Ziel, ein nationales Hochgeschwindigkeitsnetz für Behörden, Schulen, Univer- 
sitäten und Privatwirtschaft zu schaffen (National Information Infrastructure 
(Nil); vgl. z. B. Bayer (1994)). Diese gemeinsame Initiative von Regierungs- 
und Industrievertretern hatte einen Aktionsplan mit folgenden übergeordne- 
ten Zielen zur Folge: Deregulierung und Standardisierung sowie Förderung 
von (Infrastruktur-)Investitionen, Wettbewerb, Forschung, Sicherheit, Daten- 
schutz und Schutz geistigen Eigentums. Entsprechende Initiativen gab es an- 
schließend auch in Europa (vgl. Bangemann (1994)) und Deutschland, jedoch 
mit weit weniger finanziellen Mitteln. Hiermit zusammenhängend wurde je- 
doch die Deregulierung bzw. Privatisierung von Telekommunikationsunter- 
nehmen vorangetrieben. 

Im Wesentlichen hat sich heute das Internet als der Inbegriff des glo- 
balen Information Highway durchgesetzt (ohne dass dies viel mit den oben 
angesprochenen politischen Initiativen zu tun haben muss). Es ist absehbar, 
dass Internet und die „herkömmliche“ Telekommunikation zukünftig zusam- 
menwachsen werden. Man sollte sich jedoch hier der teilweise widerstreben- 
den Interessen verschiedener Gruppen (Unterhaltungselektronik, Telefonge- 
sellschaften, Hardwareindustrie, Softwareindustrie usw.) bewusst sein. 

Das Internet geht auf eine Entwicklung Ende der 1960er Jahre in den USA 
zurück (ARPANET {Advanced Research Projects Agency Network) des US- 
Verteidigungsministeriums) . Primäres Ziel war damals die Schaffung eines 
robusten (und damit dezentralen) Netzes, das heterogene Hard- und Soft- 
waresysteme miteinander verbinden sollte. Hierzu wurden verschiedene neue 
Konzepte und Protokolle entwickelt und verwirklicht. Protokolle sind in die- 
sem Zusammenhang Kommunikationsvereinbarungen, die z.B. den Aufbau 
von Datenpaketen und den Ablauf einer Kommunikation festlegen. Im Fol- 
genden sind im Zusammenhang mit den entsprechenden Anwendungen die im 
Internet am weitesten verbreiteten Kommunikationsprotokolle aufgeführt: 

• Dateitransfer (FTP: File Transfer Protocol) 

• Elektronische Post (E-Mail, SMTP: Simple Mail Transfer Protocol, POP: 
Post Office Protocol, IMAP: Internet Message Access Protocol) 

• Terminalemulation (Telnet) 

• Computer-Diskussionsforen (NNTP: Network News Transport Protocol) 

• World Wide Web (HTTP: Hypertext Transfer Protocol) 

• Videoübertragung (MBone: Multicast Backbone) 
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Das Wachstum des Internets begann mit der Verbindung von vier Hosts'^^ 
im ARPANET 1969. Anfang der 1970er Jahre wurden dann so wichtige und 
heute dominierende Protokolle wie TCP/IP und Ethernet (s.u.) entwickelt. 
1974 hatte das Internet 62 Hosts, 1984 1000 Hosts. Für die breite Öffent- 
lichkeit erfolgte der Durchbruch des Internets in den 1990er Jahren im Zu- 
sammenhang mit der Entwicklung des World Wide Web (WWW; vgl. Ab- 
schnitt 2.6) auf Basis des Internets (1992: 1 Mio. Hosts; 1995: 7 Mio. Hosts). 
Das Wachstum des Internets sei durch Abbildung 2.5 verdeutlicht. Ende 2004 
gab es in Deutschland (bzw. im Bereich der RIPE^^) ca. 3,0 Mio. (22,3 Mio.) 
ans Internet angeschlossene Rechner. 




Abbildung 2.5. Wachstum des Internets in Deutschland bzw. Europa; Quelle: 
DENIC e. G. (2005) 



Die Entwicklung des Internets ist hinsichtlich verschiedener Aspekte dy- 
namisch und sicherlich nicht abgeschlossen. Ein wesentliches Problem ist die 
Frage nach der zuständigen Organisation für die Steuerung und Kontrolle des 

Unter einem Hast versteht man einen Rechner, mit dem weitere Rechner ver- 
bunden sind, die gegebenenfalls teilweise von diesem Host abhängig sind. Heute 
setzt man typischerweise einen Host mit einem Server oder einfach mit einem 
Rechner innerhalb eines Rechnernetzes gleich. 

RIPE (Reseaux IP Europeens) ist die regionale Registrierungsinstitution für Eu- 
ropa, den mittleren Osten, Teile Asiens (die frühere UdSSR) und den nördlichen 
Teil von Afrika. 
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Internets. Dies betrifft z.B. die Bildung und Zuweisung von Adressen sowie 
die Koordination technischer Weiterentwicklungen (etwa auch hinsichtlich 
Übertragungsqualitätsgarantien) . Weitere Problemfelder sind die Gewährleis- 
tung von Datenschutz und -Sicherheit, der Schutz geistigen Eigentums sowie 
die Ethik- und Moral-Problematik. 

Der Erfolg des Internets basiert wesentlich auf vier Aspekten, die in den 
anschließenden Abschnitten beschrieben werdenü^ 

• Kostengünstige Verfügbarkeit ausreichender Übertragungskapazitäten 

• Umsetzung einer effektiven Rechnerkommunikation auf Basis einer Schich- 
tenarchitektur 

• Dominanz der TCP/IP-Kommunikationsprotokollfamilie zur Abwicklung 
der Rechnerkommunikation 

• Das WWW als einfache und effektive „Benutzeroberfläche“ für das Internet 

Diese Entwicklungen führten dazu, dass heute in Unternehmen oftmals die 
gleichen Kommunikationsprotokolle und Dienste wie im Internet verwen- 
det werden. Entsprechende unternehmensinterne Rechnernetze sowie die zu- 
gehörigen Dienste bezeichnet man dann auch als Intranet. 

2.5.1 Bandbreiten und Anwendungen 

Die Möglichkeiten für Anwendungen auf Basis von Rechnernetzen hängen 
wesentlich von der zur Verfügung stehenden Übertragungskapazität {Band- 
breite) ab. Die Bandbreite als Maß für die Datenübertragungsgeschwindig- 
keit wird in der Regel in Bit pro Sekunde angegeben (kBit/s, MBit/s, GBit/s, 
TBit/s), wobei hier die Präfixe k, M, G und T für 10^, 10®, 10® bzw. 10^® ste- 
hen. Vom Breitband spricht man typischerweise bei Bandbreiten größer als 2 
MBit/s. Beispielsweise benötigt man für eine hochwertige Sprachübertragung 
Bandbreiten bis zu 64 kBit/s, während zur kontinuierlichen Übertragung von 
hochwertigen Videodaten bei einer entsprechenden Datenkompression Band- 
breiten von ca. 2 MBit/s notwendig sein können. 

In Tabelle 2.3 ist in vereinfachter Form dar gestellt, welche Bandbreiten 
verschiedene gängige Kommunikationsnetze typischerweise (maximal) bieten 
und wie lange jeweils die Übertragung der Daten eines Universallexikons 
(600 MB, entspricht etwa der Speicherkapazität einer GD) dauern könnte. 
Die drei erstgenannten Kommunikationstechniken basieren auf der herkömm- 
lichen Festnetzverbindung eines Telefonkunden zu einer Vermittlungsstelle 
auf Basis schmalbandiger verdrillter Kupferadern. Dieses ursprünglich zur 
Sprachübertragung vorgesehene Medium kann entweder analog (per Modem) 
oder digital (per ISDN: Integrated Services Digital Network) zur Datenüber- 
tragung verwendet werden. Darüber hinaus ermöglicht die relativ neue Tech- 

Zur Vertiefung der Grundlagen von Rechnernetzen verweisen wir auf Häckel- 
mann et al. (2000), Kauffels (2002), Peterson und Davie (2004) sowie Tanenbaum 
(2003). 
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nik DSL {Digital Subscriber Line) eine erweiterte Nutzung der Leitungs- 
verbindung zur Vermittlungsstelle zur Datenübertragung auf einem von der 
Sprachübertragung nicht genutzten Frequenzspektrum. Die hiermit erzielba- 
ren Bandbreiten sind abhängig von der Leitungsqualität und -länge. Hier- 
bei wird zweckmäßigerweise in einen Hinkanal ( Upstream) vom Teilnehmer 
zur Vermittlungsstelle bzw. zum Netz und einen entsprechenden Rückkanal 
(Downstream) unterschieden. Bei der in Deutschland gebräuchlichen DSL- 
Ausprägung ADSL {Asymmetrie Digital Subscriber Line) liegen die Band- 
breiten für den Hinkanal zwischen 16 kBit/s und 1 MBit/s, während der 
Rückkanal Bandbreiten bis zu 8 MBit/s bieten kann. Hiermit ergeben sich in 
Verbindung mit kostengünstigen Pauschalraten zur Verwendung dieses Me- 
diums zum Internetzugang weitreichende Potenziale für eine ubiquitäre Nut- 
zung von Diensten über das Internet. 





Bandbreite 


Übertragung eines 
Universallexikons (600 MB) 


Festnetztelefonie: 






analog (Modem) 


56 kBit/s 


25 Std. 


ISDN 


64 kBit/s 


22 Std. 


DSL 


8 MBit/s 


10 Min. 


Mobilkommunikation: 






GSM 


14,4 kBit/s 


93 Std. 


GPRS / HSGSD 


ca. 55 kBit/s 


25 Std. 


UMTS 


2 MBit/s 


42 Min. 


Lokale Netze: 






Ethernet 


10 MBit/s 


8 Min. 


Fast- Ethernet 


100 MBit/s 


50 Sek. 


Gigabit-Ethernet 


1 GBit/s 


5 Sek. 


Weitverkehrsbreitbandnetze: 






Breitband-ISDN 


155 MBit/s 


32 Sek. 


(auf Basis von ATM) 


622 MBit/s 


8 Sek. 


Optische Fernverbindungsstrecken: 






pro Wellenlänge (OC768) 


40 GBit/s 


0,1 Sek. 


DWDM^® 


2,56 TBit/s 


0,002 Sek. 



Tabelle 2.3. Typische Bandbreiten; vgl. u. a. Scheck (2005) 



Im Folgenden sind einige Anwendungsbeispiele für verschiedene Bereiche, 
die jeweils anwendungsspezifische Anforderungen an die Bandbreiten des ge- 
nutzten Kommunikationssystems stellen, aufgeführt: 

DWDM bedeutet Dense Wavelength Division Multiplex. 
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• Persönliche Kommunikation: Sprachkommunikation, Elektronische Post 
(E-Mail), Computerkonferenz, Videotelefon, Chat 

• Unterhaltung, Bildung, Information: Pay-per-view Video, digitales Radio, 
Online-Spiele, Elektronische Journale, virtuelle Bibliotheken, E-Learning 

• Telearbeit, Telekooperation, Workflow-Computing, Fernüberwachung 

• Betriebliche Kommunikation 

— intern: Bürokommunikation, Client-Server-Anwendungen (siehe unten) 

— extern: elektronisches Marketing, Teleshopping, Telebanking, virtuelle 
Unternehmen, EDI (Electronic Data Interchange) 

• Öffentliche Aufgaben: Elektronische Wahlen, teilautomatisierte Vorgangs- 
bearbeitung, Umwelt- und Verkehrsinformationssysteme 

Eine Verbreitung solcher Anwendungen in Mobilkommunikationsnetzen war 
auf Basis von GSM {Global System for Mobile Communications) oder der 
GSM-Erweiterungen zur Datenübertragung (GPRS: (General Packet Radio 
Service) und HSCSD: (High Speed Circuit Switched Data)) kaum möglich. 
Erst die durch Mobilkommunikationsnetze der dritten Generation ( Universal 
Mobile Telecommunications System, UMTS) gebotenen Übertragungstechni- 
ken bzw. Bandbreiten bieten hier weitergehende Potenziale. 

Unter lokalen Netzen {Local Area Networks, LAN) versteht man räum- 
lich auf ein Gebäude oder eine Gebäudegruppe abgegrenzte Rechnernetze, 
wie sie typischerweise für geschlossene Teilnehmergruppen (z. B. Organisa- 
tionseinheiten eines Betriebes) verwendet werden. In der Praxis dominieren 
hier die verschiedenen Varianten der Ethernet-Protokollfamilie, die auf die 
Übermittlung von Daten auf Leitungen von einigen hundert Metern Länge 
ausgerichtet sind. Lokale Netze werden häußg privat betrieben (z. B. durch 
das jeweils nutzende Unternehmen) . Weitverkehrsbreitbandnetze werden da- 
gegen in der Regel von Telekommunikationsunternehmen betrieben, um etwa 
Endkunden bei Bedarf breitbandige Fernkommunikationsverbindungen ab- 
gestuft anzubieten oder den Datenverkehr in so genannten Backbone- Netzen 
(Kommunikationsverbindungen mit hoher Bandbreite, mittels derer Teilnetze 
verbunden werden) abzuwickeln. Verbreitet ist hier z. B. das Protokoll ATM 
{Asynchronous Transfer Mode). In der Tabelle 2.3 sind mögliche Bandbreiten 
hierbei genutzter optischer Fernverbindungsstrecken dargestellt. 

Im Zusammenhang mit der breiten Verfügbarkeit von Rechnernetzen er- 
gibt sich die Möglichkeit, Softwaresysteme auf verschiedene Rechner zu ver- 
teilen. Das Client-Server-Konzept spiegelt hierbei die wesentliche strukturelle 
Beziehung zwischen Softwarekomponenten wider: Clients nutzen die Funktio- 
nalität von Dienstanbietern (Servern) im Rahmen einer kooperativen Abwick- 
lung von Aufgaben. Hierbei bezeichnet Server nicht unbedingt (nur) einen 
Rechner, sondern eher einen speziellen Dienst (d. h. ein entsprechendes Pro- 
gramm bzw. einen entsprechenden Prozess) auf einem Rechner. Damit ist 
auch die Funktion eines Rechners nicht unbedingt festgelegt; das heißt, ein 
Rechner kann gleichzeitig Glient- und Server-Rollen übernehmen. Beispiele 
sind Dateiserver, Druckserver, Datenbankserver, Mailserver und Webserver. 




44 



2. Informatik und Informations- und Kommunikationstechnik 



Die klassische Ausprägung einer (zweistufigen) Client-Server- Architektur ist 
die Zentralisierung einer integrativen Datenhaltung auf einem Datenbankser- 
ver (vgl. Kapitel 5), auf den verschiedene Nutzer über Benutzeroberflächen 
zugreifen. Hierbei können sich (unter Berücksichtigung von Effizienzkriterien) 
Teile der eigentlichen Anwendungslogik sowohl auf dem Server als auch auf 
den Clients befinden. Eine konsequente Fortführung dieser Strukturierungs- 
form führt zu einer dreistufigen Schichtenarchitektur, in der die wesentliche 
Anwendungslogik in Anwendungsservern abgebildet ist; vgl. Abbildung 2.6. 




Abbildung 2.6. Client-Server-Architekturen 



2.5.2 Kommunikationsprotokolle 

Führt man sich die Mannigfaltigkeit der Kommunikation von Rechnern über 
Rechnernetze bzw. die hierbei zu lösenden Probleme vor Augen, so erscheint 
es sinnvoll, das Gesamtproblem der Rechnerkommunikation in kleinere Teil- 
probleme zu zerlegen. Dabei spielt die Modularisierung nach dem Prinzip 
der funktionalen Abstraktion eine wesentliche Rolle. Hierbei werden komple- 
xe Systeme in Teile zerlegt, die jeweils gewisse Funktionalitäten zu erfüllen 
haben, die über spezifizierte Schnittstellen genutzt werden können. 

Im Weiteren sei das Telefon als Beispiel für eine funktionale Abstrakti- 
on kurz diskutiert. Für den Nutzer wird die Aufgabe „Sprachkommunikation 
über Distanzen“ vereinfacht, indem er die Existenz des Telefonnetzes voraus- 
setzen kann und sich nur mit der Schnittstelle befassen muss (dem Telefon). 
Die Nutzung des Telefons ist nach einer gegebenen Spezifikation gewährlei- 
stet; d. h. der Nutzer muss nur wissen, dass ein Wählen einer Nummer (oder 
das Sprechen in den Hörer usw.) bestimmte Auswirkungen hat (ohne dass er 
Kenntnisse zur technischen Realisierung der Sprachübertragung benötigt). 

Beim in der Informatik oft verwendeten Schichtenmodell bietet jeweils 
eine (untere) Schicht der nächsten (übergeordneten)Schicht gewisse Dienste 
an (hierzu ist eine Schnittstelle spezifiziert, oft auch als Protokoll bezeichnet). 
Die Funktionalität einer Schicht wird lediglich über die Schnittstelle genutzt; 
die Implementierung eines Moduls (bzw. einer Schicht) ist davon unabhängig; 
vgl. die entsprechende Diskussion in Abschnitt 2.4.1. Potenzielle Vorteile des 
Schichtenmodells sind insbesondere die Vereinfachung komplexer Probleme 
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und die Austauschbarkeit verschiedener Module (Schichten), was u. a. eine 
technik- und herstellerneutrale offene Systemgestaltung ermöglichen kann. 

Als konzeptioneller Rahmen zur Rechnerkommunikation ist das ISO/ OSI- 
Modell (auch als ISO-Referenzmodell bezeichnet) hervorzuheben (ISO: Inter- 
national Standardization Organization; OSI: Open Systems Interconnection). 
Hierbei handelt es sich um eine Referenz-Schichtenarchitektur zur Standar- 
disierung der Datenkommunikation, bestehend aus sieben Schichten mit de- 
finierten Funktionalitäten; vgl. Abbildung 2.7. Die unteren vier Schichten 
bezeichnet man auch als Transportsystem, die oberen drei Schichten als An- 
wendungssystem . 



Rechner A 




Rechner B 




Anwendungsschicht 




7 




Application Layer 




Darstellungsschicht 
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Presentation Layer 




Sitzungsschicht 
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Session Layer 




Transportschicht 
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Transport Layer 




Vermittlungsschicht 




3 




Network Layer 




Sicherungsschicht 




2 




Datalink Layer 




Physikalische Schicht 




1 




Physical Layer 


t 







Datenübertragung 



Abbildung 2.7. 7-Schichten-Architektur des ISO/OSI- Modells 



In idealtypischer Form läuft eine Kommunikation zwischen Anwendungen 
(z. B. eine Übertragung einer Datei) auf durch ein Rechnernetz verbunde- 
nen Rechnern A und B folgendermaßen ab: Ein Anwendungsprogramm nutzt 
die spezifische Funktionalität einer geeigneten anwendungsspezifischen Aus- 
prägung der obersten Schicht über eine definierte Schnittstelle. Die Anwen- 
dungsschicht nutzt Dienste auf der Ebene der Darstellungsschicht, um etwa 
die Codierung zu vereinheitlichen. Analog werden die zu kommunizierenden 
Inhalte sukzessive an die jeweils nächsttiefere Schicht weitergeleitet (Schich- 
ten mit nicht benötigter Funktionalität können übersprungen werden), bis 
letztendlich eine Umsetzung in physische Signale erfolgt. Beim Empfänger 
werden die Schichten entsprechend umgekehrt von unten nach oben durchlau- 
fen, bis schließlich die ursprünglichen Informationen in geeigneter Form auf 
der Anwendungsebene weiterverarbeitet werden können. Im Folgenden wer- 
den kurz gefasst wesentliche Funktionalitäten und Ausprägungen der Schich- 
ten des ISO/OSI-Modells erläutert. 
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1. Physikalische Schicht: Die unterste Schicht repräsentiert die physische 
Übertragung von Bits. In diesem Zusammenhang werden etwa die tech- 
nische Auslegung von Kabeln und Steckern sowie die Codierung der ei- 
gentlichen Daten (Bits) durch (insbesondere elektrische oder optische) 
Signale fest gelegt. 

2. Sicherungsschicht: In der zweiten Schicht wird der zuverlässige Austausch 
von Datenpaketen über Funktionen wie Verbindungsaufbau, Bildung und 
Synchronisation von Datenpaketen (Frames) und Beseitigung von Über- 
tragungsfehlern realisiert. Hierbei geht man von einer direkten Verbin- 
dung über eine gemeinsame Ausprägung der physikalischen Schicht aus. 

3. Vermittlungsschicht: Sind zwei Kommunikationspartner nicht direkt ver- 
bunden, so ist eine Vermittlung der Kommunikation über Austauschstel- 
len erforderlich. Dabei ist insbesondere eine zielgerichtete Wegesteuerung 
(Routing) von Datenpaketen zu gewährleisten, wodurch die Funktiona- 
lität einer logischen bzw. virtuellen Direktverbindung realisiert wird. 

4. Transportschicht: Die oberste Schicht des Transportsystems stellt dem 
Anwendungssystem eine gesicherte Ende-zu-Ende- Verbindung zur Über- 
tragung von Daten zur Verfügung (in Abhängigkeit von entsprechenden 
Qualitätsanforderungen) . Hieraus ergeben sich Aufgaben wie die Bildung 
und Sequenzierung von Datenpaketen sowie eine geeignete Fehlerkorrek- 
tur. 

5. Sitzungsschicht: In der auch als Kommunikationssteuerungsschicht be- 
zeichneten Ebene werden insbesondere Funktionen zur Steuerung von 
Prozessdialogen unter Berücksichtigung eines unzuverlässigen Transport- 
systems bereitgestellt. Das heißt etwa, dass nach einem (temporären) 
Ausfall des Transportsystems eine (Neu-)Synchronisation durchzuführen 
ist. 

6. Darstellungsschicht: Bei der Kommunikation zwischen verschiedenen 
Rechnern bzw. Anwendungssystemen kann eine Übersetzung zwischen 
rechner- bzw. anwendungsspezifischen Datenformaten notwendig sein, 
was durch die Darstellungsschicht durchgeführt werden kann. Weitere 
mögliche Funktionen sind die Datenkompression und -Verschlüsselung. 

7. Anwendungsschicht: Auf der obersten Schicht sind die eigentlichen An- 
wendungsfunktionalitäten wie etwa die auf Seite 39 genannten Dienste 
(z.B. Dateiübertragung) angeordnet. 

Das ISO/OSI-Modell stellt eine konzeptionelle Referenz-Schichtenarchi- 
tektur dar, wobei sich nur wenige von der ISO standardisierte Ausprägun- 
gen der einzelnen Schichten durchsetzen konnten. Dagegen dominieren in der 
Praxis verschiedenste Protokolle als (Quasi-)Standards, die sich nichtsdesto- 
trotz in das ISO/OSI-Modell einordnen lassen. Dies gilt insbesondere für die 
TCP/IP-Protokollfamilie. 
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2.5.3 TCP/IP 

TCP/IP (Transmission Control Protocol/ Internet Protoeol) ist das domi- 
nierende Kommunikationsprotokoll im Internet. Es fand zunächst Verbrei- 
tung als Bestandteil von Unix-Betriebssystemen. Heute sind Implementie- 
rungen von TCP/IP für praktisch alle Betriebssysteme verfügbar bzw. in 
dieselben integriert. TCP/IP basiert auf einer 4-Schichten- Architektur, die 
in Abbildung 2.8 veranschaulicht wird. Die oberste Schicht entspricht hier- 
bei den drei oberen Schichten des ISO/OSI-Modells, die untere Schicht der 
TCP/IP- Architektur bildet das Gegenstück zu den unteren beiden Schichten 
des ISO/OSI-Modells; vgl. Abbildung 2.7. 





FTP, HTTP, SMTP, Telnet 




TCP 


IP 


N etzwerk-Interface 



Abbildung 2.8. 4-Schichten- Architektur TCP/IP 



Das Internet Protocol (IP) regelt die verbindungslose Datenübertragung 
zwischen zwei Rechnern. Hierbei werden Datenpakete schrittweise von einem 
Quellrechner zu einem Zielrechner übertragen. Hierzu wird die Funktionalität 
einer Netzwerk-Interface-Schicht genutzt (z. B. Ethernet). Das Transmission 
Control Protocol (TCP) bietet, aufbauend auf IP, die Funktionalität einer 
Ende-zu-Ende Verbindung zwischen zwei Rechnern (etwa Sicherstellung der 
korrekten Übertragung, Paketsequenzierung). Aufbauend auf dieser Funk- 
tionalität können z.B. Dienste zum Übertragen von Dateien zwischen zwei 
Rechnern (z.B. FTP) entwickelt werden, ohne dass man hierbei von der Rea- 
lisierung der Datenübertragung abhängig ist. 

Zur Verbindung von Programmen (Prozessen) auf bestimmten Rechnern 
in bestimmten Netzwerken zu anderen Programmen (Prozessen) auf ande- 
ren Rechnern in anderen Netzwerken benötigt man eine festgelegte Form 
der Adressierung. Die Adressierung im Internet basiert auf IP-Adressen für 
Netzwerke bzw. Rechner in denselben (siehe unten). Auf Basis dieser Identifi- 
kation können über so genannte Port-Nummern die anzusprechenden Dienste 
(Prozesse, Protokolle) ausgewählt werden. Beispielsweise startet eine Verbin- 
dungsanfrage zu einem Rechner mit Port-Nummer 80 eine HTTP-Verbindung 
zu dem entsprechenden Dienst auf diesem Rechner. Definierte Ports ordnen 
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Netzdienste zu. Beispiele für verschiedene solche Dienste bzw. die mit ihnen 
verbundenen Port-Nummern sind:^'^ 

• FTP: 21 

• Telnet: 23 

• SMTP: 25 

• HTTP: 80 

• POP: 110 

Mittels Port-Nummern können folglich bestimmte Dienste auf einem Rechner 
ausgewählt werden, die dort durch entsprechende Programme bzw. Prozesse 
realisiert sind. 

Die Adressierung von Rechnern ist abhängig von der Protokollebene. So 
kann insbesondere eine eindeutige Hardwareadresse von Netzwerkkarten, wel- 
che die Schnittstelle zum physischen Netzwerk bilden, eine Identifikation des 
Rechners ermöglichen. Beispielsweise ist jede Ethernet-Netzwerkkarte durch 
eine weltweit eindeutige Hardwareadresse (12-stelliger Hexadezimal-Code, 
z.B. 00-00-B4-6A-21-B4) identifiziert; hierzu wurden Herstellern disjunkte 
Adressbereiche zugeteilt. 

Ein Routing von Datenpaketen zwischen Rechnern, die nicht direkt über 
eine gemeinsame Ausprägung unterer Schichten verbunden sind, erfordert ei- 
ne Adressierung von Rechnern in Abhängigkeit von der Strukturierung von 
Netzwerken. Eine IP-Adresse besteht aus 32 Bit, typischerweise dargestellt 
durch vier (8-Bit) Zahlen von 0 bis 255. Theoretische Obergrenze für die An- 
zahl verschiedener Adressen ist folglich 2^^ = 4.294.967.296. IP-Adressen sind 
unterteilt in eine Netzadresse und eine Rechneradresse. Es gibt drei Klassen 
A, B und C von IP-Adressen (die ersten beiden Bits einer IP-Adresse co- 
dieren diese Klassen). Abhängig von der Klasse nimmt die Netzadresse 1, 2 
oder 3 Bytes ein. Ein Beispiel für eine IP-Adresse ist 134. 169.75. 180; diese 
Adresse ist eine Adresse in einem Klasse-B-Netz. Die ersten beiden Zahlen 
134.169 kennzeichnen das Netz der Technischen Universität (TU) Braun- 
schweig; 75.180 identifiziert einen spezifischen Rechner innerhalb dieses Net- 
zes. 

Ein Problem, welches sich im Zusammenhang mit solchen IP-Adressen 
abzeichnet, ist die zunehmende Adressverknappung. Dies liegt auch darin 
begründet, dass nicht alle theoretisch möglichen IP-Adressen genutzt wer- 
den (können). Beispielsweise besitzt die TU Braunschweig einen Adressbe- 
reich von theoretisch 2^® = 65.536 Adressen; davon werden aber nicht alle 
benötigt (und verbleiben damit ungenutzt). In der näheren Zukunft wird 
deshalb eine Erweiterung nötig sein. Die Internet Engineering Task Force 
(lETF) als wesentliche Standardisierungsorganisation für das Internet steu- 
ert bzw. überwacht eine entsprechende Protokollmodifikation. Voraussichtlich 

Diese und weitere Port-Nummern sind im Rahmen von RFC 1700 festgelegt. 
RFC steht für Request for Comments. Entsprechende Dokumente haben sich als 
definierende Grundlage vieler Protokolle und Regeln im Internet herausgebildet; 
vgl. http://www.rfc-editor.org. 
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wird das Nachfolgeprotokoll IPv6, das 128-Bit- Adressen (maximal 3,4 • 10^® 
Adressen)^® verwendet, schrittweise IP ablösen. 

Numerische IP-Adressen sind für den Menschen in der Regel nicht son- 
derlich komfortabel. Demzufolge kann man zur Adressierung von Rechnern 
auch Rechnernamen (Hostnames) nutzen. Die Zuordnung von Rechnerna- 
men zu IP-Adressen wird über Informationen, die in hierarchischen Daten- 
banken gespeichert sind, ermöglicht. So kann man insbesondere mittels des 
Dienstes DNS {Domain Name Service) Rechnernamen auf IP-Adressen ab- 
bilden (Rechner, die solche Funktionalität bereitstellen, bezeichnet man auch 
als Nameserver). 

Rechnernamen sind hierarchisch aufgebaut (von rechts nach links): 
„dn.dn-1.. . .d2.dl“. So ist z.B. „www.winforms.phil.tu-bs.de“ der Rechner- 
name für den Rechner mit der IP-Adresse 134. 169. 75. 180. Der am weites- 
ten rechts stehende Anteil eines Rechnernamens stellt die Top Level Domain 
(TLD) dar. Da das Internet aus den USA stammt, gibt es eine ursprünglich 
zweigeteilte Adressierung: klassifizierend länderübergreifend bzw. innerhalb 
der USA durch com, org, net, edu, gov, int und mil {Generic TLDs) und 
ansonsten geographisch in z.B. de, uk und jp {Country Code TLDs). Die 
Internet Corporation for Assigned Names and Numbers (ICANN) hat Ende 
2000 eine (umstrittene) Erweiterung des Namensraumes durch Einführung 
von einigen neuen Top Level Domains wie z. B. info und biz durchgeführt. 

Sinnvollerweise kennzeichnen die Bestandteile einer Rechneradresse die- 
sen sukzessive einschränkend. Ein Beispiel hierfür ist „www.brunel.ac.uk“. 
Dahinter verbirgt sich der WWW-Server („www“) der Brunei („brunel“) 
University („ac“, academic) im Vereinigten Königreich („uk“). Eine solche 
durchgängige Untergliederung mittels des zweiten Adressbestandteiles, wie 
in manchen Ländern üblich, ist in Deutschland nicht gängig. So ist der Name 
des WWW-Servers der TU Braunschweig schlicht „www.tu-bs.de“. 

Besitzt eine Organisation wie die TU Braunschweig eine Domain wie „tu- 
bs.de“, so können Sub-Domains hierin im Wesentlichen frei vergeben werden. 
So kennzeichnet der dritte Adressbestandteil an der TU Braunschweig ins- 
besondere Organisationseinheiten wie Fachbereiche (z. B. „bau“, „phil“) oder 
zentrale Einrichtungen (z. B. „rz“). Dies wird hierarchisch fortgesetzt, so dass 
man z.B. anhand des Rechnernamens „www.winforms.phil.tu-bs.de“ vermu- 
ten kann, dass dieser Rechner ein WWW-Server einer Abteilung mit dem 
Kürzel „winforms“ innerhalb eines bestimmten Fachbereiches („phil“) an der 
TU Braunschweig ist. 

Ein weiterer Vorteil von Rechnernamen besteht in der Flexibilität, die 
durch die indirekte Adressierung ermöglicht wird. So ist beispielsweise die 
Adresse „www.winforms.phil.tu-bs.de“ unabhängig vom konkreten Rechner, 
auf dem der WWW-Server läuft. Man könnte somit den WWW-Server auf 

Man kann leicht ausrechnen, dass auch bei sehr inefiizienter Nutzung der IP- 
Adressen mindestens 1500 IP-Adressen pro Quadratmeter der Erdoberfläche zur 
Verfügung stehen, so dass alle Fernseher, Geld- und Kaffeeautomaten u. Ä. mit 
IP-Adressen ausgestattet werden könnten. 
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einem anderen Rechner betreiben (und die Zuordnung des Rechnernamens 
zu einer IP-Nummer mittels einer Modifikation im zuständigen DNS-Server 
ändern), ohne dass der Nutzer den Zugriff auf einen anderen Rechner bemer- 
ken muss. 

Die Übertragung von Daten im Internet unterscheidet sich grundlegend 
von der herkömmlichen Übertragung von Sprache in Telefonnetzen. Während 
bei Telefonnetzen typischerweise ein dedizierter Übertragungskanal mit einer 
reservierten Übertragungskapazität zwischen zwei Endstationen aufgebaut 
wird, auf dem die Sprachinformationen quasi kontinuierlich übertragen wer- 
den {Leitungsvermittlung), erfolgt die Datenübertragung per TCP/IP nach 
dem Store-and-Forward-Frinzip {Speichervermittlung). Die zu übertragen- 
den Daten werden hierzu in Fragmente aufgeteilt; diese werden in Paketen, 
die auch Informationen wie etwa Paketnummer, Absender- und Zieladres- 
se beinhalten, schrittweise unter jeweiliger Zwischenspeicherung in Vermitt- 
lungsrechnern zur Zieladresse übertragen. 

Router verbinden verschiedene Rechnernetze. Solche Router besitzen (dy- 
namische) Informationen, wohin sie Datenpakete mit bestimmten Adressen 
weiterleiten müssen (gemäß definierter Routing-Protokolle). Beispielsweise 
leitet der Router der TU Braunschweig Datenpakete mit verschiedenen Ziel- 
adressen verschiedenartig weiter. So wird ein Datenpaket mit Zieladresse 
134.169.X.X gar nicht (bzw. intern) weitergeleitet, da es sich um eine Rech- 
neradresse innerhalb der TU handelt, während bei einer anderen Zieladresse 
eine Weiterleitung nach außen erfolgt. 

Im Weiteren sei anhand eines Beispieles der Weg eines Datenpaketes im 
Internet veranschaulicht. Die folgende Liste stellt die Stationen eines Daten- 
paketes vom Netz der Universität Hamburg zum WWW-Server der Zeitschrift 
„Der Spiegel“ dar (protokolliert am 30. März 2005, 21 Uhr): 

Routenverfolgung zu www.spiegel.de [195.71.11.67] über maximal 30 



Abschnitte: 




1 


<1 ms 


134.100.134.254 


2 


<1 ms 


Core-RRZ2-RI.rrz.uni-hamburg.de [134.100.250.240] 


3 


<1 ms 


nixgat-ge-crrz2.rrz.uni-hamburg.de [134.100.254.174] 


4 


<1 ms 


ar-hamburg3-ge0-0-900.g-win.dfn.de [188.1.47.37] 


5 


<1 ms 


cr-hamburgl-ge5-0.g-win.dfn.de [188.1.92.1] 


6 


5 ms 


cr-berlinl-poO-O.g-win.dfn.de [188.1.18.109] 


7 


13 ms 


cr-frankfurtl-pol3-0.g-win.dfn.de [188.1.18.54] 


8 


13 ms 


ir-frankfurt2-po4-0.g-win.dfn.de [188.1.80.46] 


9 


13 ms 


188.1.56.2 


10 


13 ms 


rmwc-frnk-de01-pos-l-2.nw.mediaways.net [213.20.249.201] 


11 


20 ms 


rmwc-gtso-deOl-pos-1-0. nw.mediaways.net [195.71.254.121] 


12 


20 ms 


195.71.13.76 


13 


20 ms 


195.71.11.67 



Anhand dieser Liste erkennt man, dass die Übertragung eines Datenpaketes 
in diesem konkreten Fall unter Nutzung von zwölf Zwischenstationen (so 
genannten Hops) bis zum Zielrechner in ca. 20 ms möglich war. Der „Weg“ 
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von Datenpaketen im Internet ist nicht statisch festgelegt, sondern verändert 
sich in der Regel dynamisch. Gleiches gilt auch für die Übertragungsdauern. 

Das folgende Beispiel zeigt, dass die physische Nähe eines Zielrechners 
nicht unbedingt bedeuten muss, dass dieser Rechner über nur wenige Zwi- 
schenstationen erreicht wird: 



Routenverfolgung zu www.hamburgische-staatsoper.de [213.70.135.31] 
über maximal 30 Abschnitte: 



1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 



<1 ms 134.100.134.254 

<1 ms Core-RRZ2-RI.rrz.uni-hamburg.de [134.100.250.240] 

<1 ms nixgat-ge-crrz2.rrz.uni-hamburg.de [134.100.254.174] 

<1 ms ar-hamburg3-ge0-0-900.g-win.dfn.de [188.1.47.37] 

<1 ms cr-hamburgl-ge5-0.g-win.dfn.de [188.1.92.1] 

4 ms cr-berlinl-poO-O.g-win. dfn.de [188.1.18.109] 

5 ms ir-berlinl-geO-O-O.g-win. dfn.de [188.1.20.36] 

6 ms 149.227.129.25 

7 ms 331.atl-l-0.CRl.BER2.ALTER.NET [149.227.25.169] 

11 ms so-0-0-0.CRl.HNR2.ALTER.NET [149.227.17.145] 

11 ms so-7-0-0.CR2.HNR2.ALTER.NET [149.227.20.190] 

16 ms so-2-0-0.CRl.DTMl.ALTER.NET [149.227.30.93] 

17 ms 312.atm-8-0-0.dtmleusodhr4.dtm.ops.eu.uu.net [149.227.48.150] 

17 ms www.hamburgische-staatsoper.de [213.70.135.31] 



Die Begründung für die relativ hohe Anzahl an Zwischenstationen und den 
„Umweg“ über Berlin liegt darin, dass die Quell- und Zielrechner Teil von 
Netzen verschiedener Provider sind. Solche Provider unterhalten typischer- 
weise eigene Backbone-Netze, zwischen denen in der Regel nur wenige Über- 
gangspunkte bestehen. 



2.6 World Wide Web 

Das World Wide Web (WWW) kann man als verteiltes, multimediales (z. B. 
Text, Bilder, Sprache, Musik, Video) Informationssystem bezeichnen. Basie- 
rend auf der Kommunikationsinfrastruktur des Internets und der Idee des 
Hypertextes (Navigieren durch Verweise) hat sich das WWW als universel- 
les Werkzeug zur Massenkommunikation herausgestellt. Jeder ist im Internet 
gleichzeitig Nutzer (Informationsnachfrager) und potenzieller Anbieter. 

Im WWW ist es gelungen, auf Basis eines Übertragungsprotokolls 
(HTTP) sowie einer Sprache zur dokumentenorientierten Beschreibung der 
Darstellung und Verknüpfung von Informationen (HTML: Hypertext Mark- 
up Language) eine einfache Benutzeroberfläche für das Internet zu schaffen. 
Während es bis Anfang der 1990er Jahre im Internet viele verschiedene Pro- 
tokolle gab, die für den durchschnittlichen Anwender aufgrund einer not- 
wendigen Beherrschung entsprechender Befehlssprachen kaum nutzbar wa- 
ren, kapseln nunmehr WWW-Browser (wie z. B. Microsoft Internet Explorer 
und Mozilla Firefox) die wesentlichen Protokolle und bieten dem Nutzer eine 
einfache graphische Oberfläche für das Internet. 
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Das Basiskonzept zur Adressierung von Diensten im WWW ist der Uni- 
form Resource Locator (URL)^®. Zweck eines URLs ist die Spezifikation des 
Zugriffes auf bestimmte Ressourcen auf bestimmten Rechnern unter Nutzung 
geeigneter Protokolle. URLs sind prinzipiell folgendermaßen aufgebaut: 

protocol : / / hostname / path 

In allgemeiner Form können auch Berechtigungsangaben und eine Port- 
Nummer integriert werden: 

[prrotocol -]/ /[user[\ password\@]hostname[\ port][/ path\ 

Optionale Bestandteile sind hier in eckigen Klammern eingefasst. Sofern die 
Port-Nummer nicht angegeben ist, wird diese aus der dem Protokoll zuge- 
ordneten Standardnummer abgeleitet (z. B. 80 für HTTP). Typische Beispiele 
für URLs sind: 

• http : / /www . rrz . uni-hamburg . de/IWI/ 

• ftp: //ftp . dante . de/tex-archive/ inf o/lshort/german/12kurz .pdf 

2.6.1 HTML 

Zur Darstellung von Informationen im WWW wurde die Hypertext Mark- 
up Language entwickelt, die eine Auszeichnungssprache für Hypertext- 
Dokumente darstellt. Das wesentliche Konzept einer solchen Sprache ist die 
logische Untergliederung von Texten mittels definierter Marken (Tags), die 
zumeist geschachtelte Bereiche definieren. Dies sei durch folgende einfache 
HTML-Beispiele verdeutlicht: 

• <H1> Dies ist eine Überschrift der Stufe 1 </Hl> 

• <P> kapselt einen Absatz </P> 

• <HR> zeichnet eine horizontale Linie 

Mittels Hypertext können Verknüpfungen zwischen Informationen bzw. 
Dokumenten abgebildet werden. Ein Hypertext-System lässt sich als ein 
Graph mit Knoten (den Informationseinheiten) und Kanten (den Ver- 
knüpfungen bzw. Hyper Links) zwischen diesen abbilden. Per HTML werden 
solche Verknüpfungen folgendermaßen dar gestellt: 

• <A HREF="http : //www. tu-bs . de"> Link auf die 

Hauptseite der TU Braunschweig</A> 

Im Folgenden ist ein einfaches Beispiel für ein vollständiges HTML- 
Dokument dargestellt: 

Oftmals wird hierfür auch der Begriff Uniform Resource Identifier (URI) ver- 
wendet, der jedoch eine allgemeinere Bedeutung besitzt. So können URIs nicht 
nur zur Identifizierung des Speicherortes einer Datei auf einem Web-Server (wie 
URLs) verwendet werden, sondern es können beliebige frei wählbare Namen zur 
Identifikation einer (abstrakten) Ressource bestimmt werden. Ein URL ist somit 
ein Spezialfall eines URL 
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<!D0CTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> 

<HTML> 

<HEAD> 

<TITLE>Einf aches HTML-Dokument</TITLE> 

</HEAD> 

<B0DY> 

<Hl>Einf aches HTML-Dokument</Hl> 

<P>Dies ist ein Absatz in einem sehr einfachen 
HTML-Dokument mit einem Hypertext Link.</P> 

<P>Dies ist der zweite Absatz, der einen Link 
auf den <A HREF="http : //www. tu-bs . de">WWW-Server 
der TU Braunschweig</A> enth&aumljlt .</P> 

</B0DY> 

</HTML> 

Die Anforderungen und dementsprechend die Ausdrucksmöglichkeiten 
von HTML entwickeln sich weiter, was dazu führt, dass zur Gestaltung hin- 
reichend komplexer Dokumente in der Regel Werkzeuge verwendet werden, 
die den Nutzer von der Syntax abschirmen. Die Weiterentwicklung und Stan- 
dardisierung^^ von HTML bzw. allgemein von WWW-Protokollen wird vom 
World Wide Web Consortium (W3C) koordiniert.^® Die Problematik der fort- 
laufenden Erweiterungsanforderungen für HTML führte dazu, dass HTML 
auf Basis von XML (vgl. Abschnitt 2.6.2) neu definiert wurde (XHTML: 
Extensihle Hypertext Markup Language). 

Abschließend ist darauf hinzuweisen, dass HTML-Dokumente im Wesent- 
lichen statisch sind. Demzufolge gibt es verschiedene Konzepte, um dynami- 
sche Aspekte, wie sie zur Ausführung typischer Anwendungen normalerweise 
benötigt werden, zu integrieren. Hier konkurrieren Ansätze wie Java (Idee: 
dynamisches Laden von portablem Code, der vom Browser mit integrierter 
Java- Ablaufumgebung ausgeführt wird) und Erweiterungen um dynamische 
Aspekte auf Client- und Server-Seite (z. B. über Skript-Sprachen). In letzter 
Konsequenz führt dies dazu, dass sich Browser als universelle Benutzerober- 
flächen für betriebliche Anwendungssysteme eignen können. 



2.6.2 XML 

Die Extensihle Markup Language (XML) ist eine textbasierte und plattform- 
unabhängige Auszeichnungssprache für die strukturierte Repräsentation und 
den Austausch von Informationen; vgl. W3C (2005) sowie z. B. Ray (2004). 
Die grundlegende XML-Syntax legt z.B. fest, dass durch Tags abgegrenz- 
te Elemente eines Dokuments hierarchisch angeordnet werden müssen. Im 

In diesem Zusammenhang sollte man sich klar darüber sein, dass die Weiterent- 
wicklung und Standardisierung einer Sprache bzw. eines Protokolls komplex ist. 
Wer definiert z. B. Standards? Unabhängige Organisationen oder die Unterneh- 
men mit der größten Marktmacht? Vgl. hierzu etwa Häckelmann et al. (2000), 
S. 43-52. 

Vgl. http://www.w3.org bzw. http://www.w3.org/MarkUp. 
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Rahmen eines XML-Dokuments können einerseits konkrete Inhalte repräsen- 
tiert werden; vgl. das Beispiel für Containertransporte auf S. 55. Andererseits 
können mit XML auch spezifische XML-basierte Sprachen definiert werden, 
wobei XML die Rolle einer Metasprache einnimmt. (Die Wireless Markup 
Language (WML), die im Rahmen des auf Mobilkommunikation ausgerichte- 
ten Wireless Application Protocol (WAP) verwendet wird, ist beispielsweise 
XML-basiert.) 

Spezifische Dokumenttypen werden im Rahmen einer Document Type De- 
finition (DTD) oder eines XML-Schema-Dokuments (XSD) festgelegt. So be- 
stehen beispielsweise XHTML-Dokumente aus einem Header, in dem u. a. 
der Titel des Dokuments enthalten sein kann, und einem Body, der die In- 
formationen der Webseite und ihren Aufbau (Überschriften, Absätze, Links 
usw.) enthält. In Dokumenttypen werden etwa zulässige Elemente (bzw. ent- 
sprechende Tags) einschließlich ihrer Anordnung, ihrer Häufigkeit und gege- 
benenfalls vorhandener Attribute festgelegt. Ein XML-Dokument, was der 
grundlegenden XML-Syntax genügt, bezeichnet man als wohlgeformt. Sofern 
außerdem noch eine Validierung hinsichtlich eines bestimmten Dokumenttyps 
gegeben ist, bezeichnet man ein XML-Dokument in diesem Zusammenhang 
als gültig. 

Die Überprüfung von XML-Dokumenten auf Wohlgeformtheit und Gültig- 
keit kann von so genannten Parsern vorgenommen werden. Bei der Verwen- 
dung spezieller XML-Editoren für die Erstellung von XML-Dokumenten wird 
diese Überprüfung von einem integrierten Parser ggf. bereits bei einer inter- 
aktiven Eingabe vorgenommen; vgl. u. a. Anders et al. (2002). 

Möchte beispielsweise eine Spedition für zu transportierende Container 
relevante Informationen zum Transport strukturiert in einem Dokument able- 
gen, so dass andere am Transport beteiligte Unternehmen und deren Anwen- 
dungssysteme diese Daten automatisiert verwenden können, kann XML zum 
Einsatz kommen. Hierfür sind zunächst die allgemeinen Elemente derartiger 
Transportdokumente zu definieren. Hierzu gehören zum einen Daten zum 
Container, wie eine eindeutige Identifikationsnummer des Containers sowie 
das Gewicht. Zum anderen sollen die Dokumente Daten zum Transport ent- 
halten, u. a. den Versender, den Empfänger und alle Zwischenstationen (z.B. 
Häfen, in denen der Container umgeschlagen wird). Für alle Elemente ist zu 
untersuchen, ob eine Untergliederung in weitere Elemente sinnvoll sein kann, 
so z. B. die Unterteilung von Versender und Empfänger in Name und Adresse, 
die wiederum unterteilt werden kann in Straße, Hausnummer, Ort, Postleit- 
zahl und Land. Gleichzeitig erhält man hierdurch bereits eine zweckmäßige 
Struktur der Elemente untereinander, wie Reihenfolge, Verschachtelung und 
Häufigkeit. Jedes Element kann außerdem bestimmte Attribute besitzen, z. B. 
die Maßeinheit für das Gewicht des Containers. Bei Verwendung einer DTD 
kann ein entsprechender Dokumenttyp etwa folgendermaßen definiert werden: 

• <! ELEMENT Gewicht (\#PCDATA)> 

wird verwendet, um das Element Gewicht zu definieren, das eine beliebige 
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Zeichenfolge als Inhalt besitzen kann, was durch (#PCDATA) verdeutlicht 
wird. 

• <! ELEMENT Versender Name, Adresse) > 

definiert den Tag Versender, der als Inhalt die beiden Elemente Name 
und Adresse besitzt. Diese beiden Elemente müssen zusätzlich definiert 
werden. 

• <! ELEMENT Zwischenstationen (Station) *> 

legt fest, dass das Element Zwischenstationen mehrere Elemente des 
Typs Station enthalten darf. Das Zeichen * am Ende bedeutet, dass es 
keine oder beliebig viele Stationen geben kann. Ist mindestens eine Station 
unbedingt erforderlich, muss stattdessen das Zeichen + verwendet werden. 

• <!ATTLIST Gewicht 

Einheit CDATA \#REQUIRED 

> 

erzeugt eine Liste von Attributen zu dem bereits definierten Element 
Gewicht. Hier wird nur ein Attribut (Einheit) mit beliebigen Zeichen als 
Inhalt (CDATA) festgelegt, das immer vorhanden sein muss (#REQUIRED). 
Für optionale Attribute wird stattdessen #IMPLIED verwendet. 

• <! ELEMENT Land (Deutschland I China) > 

kennzeichnet eine alternative Auswahl für das Element Land, d.h. 
innerhalb dieses Elements ist nur einer der vorgegebenen Einträge 
(Deutschland I China) erlaubt. 

Das folgendende beispielhafte Dokument ist als Ausprägung des Doku- 
menttyps eine gültige Repräsentation eines Containertransports: 

<?xml version="l . 0"?> 

<!D0CTYPE Transport SYSTEM "Containertransport .dtd"> 
<?xml-stylesheet type="text/css" href=" Containertransport . css"> 
<Transport> 

<Containerdaten> 

<Nummer>123456</Nuimiier> 

<Gewicht Einheit="kg">10000</Gewicht> 

</ Containerdaten> 

<Transportdaten> 

<Versender> 

<Name>PC AG</Name> <Adresse>Peking</Adresse> 

</Versender> 

<Empf aenger> 

<Name>IWI, Uni Hamburg</Name> <Adresse>Hamburg</Adresse> 
</Empf aenger> 

<Zwischenstationen> 

<Station>SIPG, Shanghai</Station> 

<Station>Containerterminal Altenwerder, Hamburg</Station> 

< /Zwi s ebenst at i onen> 

</Transportdaten> 

</Transport> 



Auf die zuvor definierte DTD wird in der zweiten Zeile des Dokuments 
verwiesen, wobei Transport der Name des Dokumenttyps und gleichzeitig der 
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äußere Tag im XML-Dokument ist, der die eigentlichen Daten umschließt. Die 
DTD-Datei (containertransport . dtd) ist explizit angegeben. Eine andere 
Möglichkeit der Deklaration der DTD besteht darin, eine öffentlich zugäng- 
liche DTD zu nutzen, was mit Angabe von PUBLIC (statt SYSTEM) geschieht; 
vgl. das HTML-Beispiel auf S. 53. 

In der dritten Zeile des zuletzt gezeigten Dokuments ist ein so genann- 
tes Stylesheet angegeben. Hiermit wird auf Formatierungsangaben verwie- 
sen, die die Präsentation des Dokumentinhalts als ein zweckmäßiges HTML- 
Dokument festlegen. Damit wird eine Trennung des Layouts (z.B. Schriftart 
und -größe, Farbe, Einrückungen) von der eigentlichen inhaltlichen Struk- 
tur von Dokumenten erreicht. In diesem Fall kommen so genannte Cascading 
Stylesheets (CSS) zum Einsatz. Im Allgemeinen kann auch die XML-basierte 
Sprache XSL {Extensihle Stylesheet Language) verwendet werden. In diesem 
Rahmen können per XSLT {Extensihle Stylesheet Language for Transfor- 
mation) Dokumente in ein Zielformat überführt werden. Hierbei ermöglicht 
XPath den selektiven Zugriff auf bestimmte Elemente eines XML-Dokuments, 
während Präsentationsangaben durch so genannte XML Formatting Objects 
erfolgen. Der Einsatzbereich von XSL erstreckt sich auf die generelle Trans- 
formation von XML-Dokumenten (beispielsweise zwischen verschiedenen Do- 
kumenttypen im gleichen Anwendungsbereich), was im Zusammenhang mit 
der Interoperabilität zwischen Anwendungssystemen von großer Bedeutung 
ist. 

Ein Nachteil von DTDs besteht darin, dass hierbei nicht die übliche 
XML-Syntax verwendet, was etwa besondere Editoren und Parser erforder- 
lich macht. Darüber hinaus ist mittels einer DTD keine nähere Spezifizierung 
des Datenformats von Elementen möglich. Vor diesem Hintergrund wurde 
XML Schema (XSD) entwickelt. XML-Schema ist mächtiger und aufgrund 
der XML-Syntax auch leichter zu verarbeiten. Für das obige Beispiel könnte 
eine XML-Schema-Datei folgendermaßen aufgebaut sein: 

<?xml version=" 1 . 0" encoding="UTF-8" ?> 

<xsd: Schema xmlns : xsd="http : / /www . w3. org/2001/XMLSchema"> 

< X s d : annot at i on> 

<xsd: documentation> 

Erfassung von Containertransporten 
</xsd:documentation> 

</xsd: annotation> 

<xsd:element name="Transport" type="TransportTyp" /> 

<xsd: complexType name="TransportTyp"> 

<xsd : sequence> 

<xsd:element name="Containerdaten" type=" Containerdaten" /> 
<xsd:element name="Transportdaten" type="transportdaten" /> 
</xsd: sequence> 

</xsd : complexType> 

<xsd: complexType name="containerdaten"> 

<xsd : sequence> 

<xsd:element name=" Nummer" type="xsd: decimal" /> 
<xsd:element name="Gewicht"> 
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<xsd: simpleType> 

<xsd:restriction base="xsd:positiveInteger" /> 
</xsd: simpleType> 

</xsd : element> 

</xsd: sequence> 

</xsd : complexType> 

<xsd: complexType naine="transportdaten"> 

<xsd: sequence> 

<xsd : element name="Versender" type="versender" /> 

<xsd: element name="Empf aenger" type="versender" /> 

<xsd : element name=" Zwischenstationen" 

type="zwischenstationen" /> 

</xsd: sequence> 

</xsd : complexType> 

<xsd: complexType name="versender"> 

<xsd: sequence> 

<xsd:element name="Name" type="xsd: string" /> 

<xsd: element name="Adresse" type="xsd: string" /> 

</xsd: sequence> 

</xsd : complexType> 

<xsd: complexType name="zwischenstationen"> 

<xsd: sequence> 

<xsd: element name="Station" type="xsd: string" 
min0ccurs="0" max0ccurs="50" /> 

</xsd: sequence> 

</xsd : complexType> 

</xsd: schema> 

Mit dieser XML-Schema-Definition wird zusätzlich zur DTD festgelegt, dass 
als Nummer eine Dezimalzahl anzugeben ist, das Gewicht eine positive ganze 
Zahl sein muss und das Element Station höchstens 50-mal auftreten kann 
(maxOccurs= " 50 " ) . 



2.6.3 Web Services 

Rechnernetze ermöglichen die rechnerübergreifende Kopplung von Program- 
men, etwa im Zusammenhang mit dem Client-Server-Konzept; vgl. Abschnitt 
2.5.1. So erscheint es gerade auf der Grundlage des Internets möglich, in An- 
wendungssysteme softwaretechnische Dienste Dritter zu integrieren, was im 
Zusammenhang mit einer auf Wiederverwendung ausgerichteten Software- 
entwicklung zu sehen ist; vgl. Abschnitt 6.4. Hierfür sind Standards erforder- 
lich, die die Interoperabilität durch einen definierten Nachrichtenaustausch 
im Rahmen lose gekoppelter Systeme regeln. Hierbei spielen Web-Service- 
Techniken eine große Rolle; vgl. z.B. Alonso et al. (2004). 

Ein Weh Service ist ein gekapselter softwaretechnischer Dienst, der auf 
der Grundlage von Kommunikationsprotokollen des World Wide Web durch 
nicht lokale Softwaresysteme genutzt werden kann. Die Interaktion zwischen 
Dienst-Nutzer (Glient) und Dienst- Anbieter (Service) verläuft dabei automa- 
tisiert nach dem folgenden idealtypischen Schema (vgl. Abbildung 2.9): 
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• Web Services registrieren sich in einem Web-Service-Katalog (einem so 
genannten Repository) und hinterlegen dort ihre Beschreibung, die im In- 
ternet veröffentlicht wird. 

• Der Client sucht selbstständig im Repository nach einem Web Service, der 
die gewünschte Funktionalität (z.B. die Überprüfung der Bonität eines 
potenziellen Kunden) bietet. 

• Der Client ruft diesen Web Service auf (Request) und verwendet anschlie- 
ßend die vom Web Service zurückgegebenen Daten (Response; z. B. die 
Bonität). 




Abbildung 2.9. Zugriff auf Web Services; nach Brüssau (2005), S. 383 



Um diese Integration und Automation zu erreichen, müssen Web Ser- 
vices eine Reihe von standardisierten Protokollen und Schnittstellen für die 
Interaktion einhalten. Für den Austausch der Nachrichten beim Aufruf von 
Web Services hat sich SOAP als Standard durchgesetzt. SOAP basiert auf 
XML und kapselt die zu übertragenden Daten in einen so genannten SOAP- 
Envelope (Umschlag) . Dieser besteht aus einem Header und einem Body mit 
den zu übermittelnden XML-Daten. Der Header darf leer sein, kann aber bei- 
spielsweise Informationen darüber enthalten, wer in welcher Reihenfolge die 
im Body enthaltenen Daten verarbeiten darf. Somit können kleinere Prozesse 
in einer SOAP-Nachricht abgebildet werden. 

Für die Erstellung von Repositorys von verfügbaren Web Services gibt 
es den Standard UDDI (Universal Description, Discovery and Integration). 
Innerhalb eines UDDI-Repositorys erfolgt die Beschreibung des Web Services 
sowie des entsprechenden Anbieters anhand der folgenden drei Ebenen (vgl. 
z.B. Beimborn und Weitzel (2003)): 

• White Pages enthalten die Kontaktdaten des Dienst- Anbieters, 

• Yellow Pages beschreiben die Funktionalität des Web Services und klassi- 
fizieren ihn, 

• Green Pages beinhalten die technischen Spezifikationen des Web Services. 
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Für die technische Spezifikation von Web Services hat sich die Web Ser- 
vices Description Language (WSDL) zum Standard entwickelt. Hiermit wer- 
den die Schnittstellen von Web Services, insbesondere der Aufbau der ein- 
und ausgehenden SOAP-Nachrichten, beschrieben. 



2.7 Übungen nnd Kontrollfragen 

2.7.1 Berechenbarkeit und Komplexität 

1. Für das Sortierproblem kann man nachweisen, dass die Laufzeitkomple- 
xität ß(nlogn) beträgt. Wie lässt sich diese Aussage interpretieren? 

2. Die Auswirkungen einer exponentiellen Laufzeitkomplexität können 
an folgendem Beispiel veranschaulicht werden. Es sei angenommen, 
dass für eine gegebene Problemstellung praxisrelevante Instanzen eine 
Größenordnung von circa n = 100 aufweisen. Wie schnell müsste ein 
Rechner sein (ausgedrückt in Elementaroperationen pro Sekunde), damit 
entsprechende Probleminstanzen mit einem Algorithmus mit einem Auf- 
wand von 2” Elementaroperationen innerhalb einer Stunde lösbar wären? 

3. Das Aquivalenzproblem besteht darin, zu entscheiden, ob zwei Pro- 
gramme dieselbe Funktion berechnen. Ist das Aquivalenzproblem 
berechenbar? 

4. Ihr Chef beauftragt Sie mit der Entwicklung eines Programms, das die 
Tourenlängen von Auslieferungsfahrten minimiert. Dieses Problem ent- 
spricht dem Rundreiseproblem. Was könnten Sie Ihrem Chef antworten? 

5. Betrachten Sie die folgenden Programme (beschrieben in der WHILE- 
Programmiersprache) . Gehen Sie hierbei davon aus, dass das jeweilige 
Programm mit einer vorbelegten Variable n als Eingabeparameter 
aufgerufen wird (n stellt eine positive ganze Zahl dar). 

a) r := 0; 

a := 0; 

while o ^ n do 
o := a -I- 1; 
b := 0; 

while b ^ a do 
r := r 1; 
b := & -|- 1; 

end; 

end; 
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b) s := 0; 
t := 0; 

while t n do 
t '.= t 
V := 0; 

while V 7 ^ 256 do 
s := s -I- 1; 

end; 

end; 

Geben Sie die Laufzeitkomplexität dieser Programme in Abhängigkeit 
von dem Parameter n mittels der 0-Notation an! 

6. Gehen Sie davon aus, dass Sie für eine Problemstellung, bei der die 
Größe von Probleminstanzen über den Parameter n spezifiziert sei, 
einen Lösungsalgorithmus mit einem zeitlichen Aufwand von a) 
bzw. b) 2" Zeiteinheiten nutzen. Wie wirkt sich eine Vervierfachung 
der Rechnergeschwindigkeit hinsichtlich der Problemgrößen, die in einer 
festen Zeitspanne gelöst werden können, aus? 

7. Sie haben in der objektorientierten Programmiersprache Java ein funk- 
tionsfähiges Programm zur Lösung unbestimmter Integrale entwickelt. 
Ist die entsprechende Problemstellung auch mittels Programmen, die in 
der Maschinensprache eines Pentium-Prozessors implementiert werden, 
lösbar? 

8. Eine Möglichkeit zur Bewertung der Korrektheit eines Programms, das 
eine Funktion f : M ^ N für eine endliche Menge M berechnen soll, 
ist Folgende: Das Programm wird für alle Eingaben ausgeführt; die 
Ausgaben des Programms werden jeweils auf Übereinstimmung mit den 
(aus einer Wertetabelle bekannten) Ergebniswerten geprüft. Ist durch 
diese Vorgehensweise die Entscheidung der Korrektheit von Programmen 
berechenbar? 

9. In einer kommerziellen Software wird folgender Algorithmus zur Be- 
stimmung eines kürzesten Weges zwischen zwei bestimmten Knoten 
eines Graphen verwendet: Es werden sukzessive alle möglichen Wege 
konstruiert und jeweils deren Länge berechnet. Aus diesen Wegen wird 
ein kürzester Weg ausgewählt. 

a) Wird mittels dieses Algorithmus tatsächlich ein kürzester Weg 
ermittelt? 
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b) Welche Laufzeitkomplexität besitzt der vorgeschlagene Algorithmus? 

c) Was können Sie aufgrund der in 9a) und 9b) gegebenen Antworten 
über den Aufwand zur Lösung des Kürzeste- Wege-Problems in Gra- 
phen aussagen? 

2.7.2 Bits & Bytes 

1. Führen Sie die folgenden Umrechnungen zwischen Zahlensystemen durch: 

a) Geben Sie die im Hexadezimalsystem dargestellte Zahl GOhex im 
Dezimalsystem an! 

b) Geben Sie die im Dualsystem (Basis: 2) dargestellte Zahl 
lOllOOllduai im Dezimalsystem an! 

c) Geben Sie die im Oktalsystem (Basis: 8) dargestellte Zahl 352okt im 
Dualsystem an! 

2. Wie lange dauert die Übertragung eines Bildes über ein Kommu- 
nikationsnetz mindestens, wenn man von folgenden vereinfachenden 
Annahmen ausgeht: Das Bild besteht aus 200 x 400 Bildpunkten; 
jeder Bildpunkt entspricht einer von 256 Farben; es wird ein einfacher, 
nichtkomprimierender Standard zur Godierung von Bildinformationen 
als Bitmuster verwendet; der restringierende Faktor bei der Übertragung 
ist die Kapazität eines ISDN-Kanals: 64000 Bit/s. 

3. Zur Finanzierung eines Informationsangebotes im WWW sollen auf 
den HTML-Seiten Logos von Sponsoren aufgenommen werden. Eine 
typische Seite beanspruche eine Größe von 100 KB. Die Logos nehmen in 
ihrer Originalgröße unkomprimiert zusammen 1,5 MB in Anspruch. Der 
Internet-Provider, bei dem Ihr Informationsangebot auf einem Server 
abgelegt ist, verfügt über einen Internet-Anschluss mit einer Bandbreite 
von 100 KByte/s. Wie lange dauert es mindestens, diese Seite mitsamt 
der unveränderten Logos herunterzuladen? Um wie viel Prozent müssen 
die Logos verkleinert werden, damit das Herunterladen der WWW-Seite 
nur noch ca. 4 Sekunden dauert? 

4. Multiplizieren Sie die beiden folgenden, in wissenschaftlicher Notation 
angegebenen Gleitkommazahlen: a = 0,621E— 1; b = 0,41E2. Geben Sie 
das Ergebnis ebenfalls in wissenschaftlicher Notation an! 
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2.7.3 World Wide Web 

1. Ein Buchhändler möchte seinen Kunden eine XML-basierte Bestellung 
ermöglichen, bei der alle wichtigen Bestelldaten in einer XML-Datei an 
den Produzenten geschickt werden können. Zu diesen Daten gehören 
folgende Kundendaten: Name des Kunden, Kundennummer und Lie- 
feranschrift (bestehend aus Straße mit Hausnummer, Postleitzahl und 
Ort). Die Bestellung selbst kann beliebig viele (jedoch mindestens einen) 
Artikel enthalten. Zu jedem bestellten Artikel sollen die Artikelnummer, 
der Artikelname, der Einzelpreis sowie die Bestellmenge angegeben 
werden. Da der Buchhändler auch nach Österreich liefert, ist bei der 
Postleitzahl als Attribut das Länderkennzeichen (D bzw. A) anzugeben. 

a) Erstellen Sie eine DTD für die XML-basierten Bestelldateien! 

b) Der Kunde Stefan Voß mit der Kundennummer 987654 möchte vier 
Exemplare des Buches „Grundlagen der Wirtschaftsinformatik“ (Nr. 
3-7908-1375-3) zum Preis von 19,94 € und ein Buch „Informations- 
management“ (Nr. 3-540-67807-7) zum Preis von 29,95 € bestellen. 
Die Bücher sollen in den Von-Melle-Park 5 in 20146 Hamburg gelie- 
fert werden. Erstellen Sie für diese Bestellung ein XML-Dokument 
auf Basis der in a) erstellten DTD! 
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„Die moderne Welt, erkenntnistheoretisch, soziologisch und ökono- 
misch betrachtet, hört auf ein neues Stichwort. Es lautet Information. 
Informationen sind die neuen Steine der Weisen, mit denen auch 
die weniger Weisen zu bauen suchen, Informationstechnologien die 
neuen Zauberstäbe, die die Welt lesbar und verfügbar machen, ein 
modernes Abrakadabra, das die Welt auf Bildschirme zaubert und 
mehr Antworten bereitzuhalten scheint, als Fragen verfügbar sind.“ 
(Mittelstraß (1992), S. 221) 

„Informationsmanagement ist die wirtschaftliche (effiziente) Pla- 
nung, Beschaffung, Verarbeitung, Distribution und Allokation von 
Informationen als Ressource zur Vorbereitung und Unterstützung 
von Entscheidungen beziehungsweise Entscheidungsprozessen sowie 
die Gestaltung der dazu erforderlichen Rahmenbedingungen.“ (Vgl. 
Schneidereit und Voß (1998) sowie Voß und Gutenschwager (2001), 

S. 70.) 

In der Unternehmenspraxis müssen ständig Entscheidungen getroffen wer- 
den. Beispielsweise müssen Unternehmen, die ihre Produkte nicht direkt kun- 
denauftragsorientiert fertigen, sondern (auf Basis von Absatzprognosen) für 
den Markt produzieren, entscheiden, wann welche Mengen welchen Produk- 
tes gefertigt werden sollen. Ein Ziel hierbei ist es, möglichst genau die Menge 
an Produkten herzustellen, die auf dem Markt verkäuflich ist. Entscheidungs- 
grundlage sind demnach (möglichst genaue) Informationen darüber, welche 
Mengen eines Produktes in Zukunft abgesetzt werden können, d. h. es müssen 
Absatzprognosen erstellt werden. Grundlage hierfür sind wiederum Informa- 
tionen, z. B. Ergebnisse von Umfragen bei potenziellen Kunden oder auch 
Absatzzahlen der Vergangenheit. 

Das Informationsmanagement (IM) kann derartige Entscheidungsprozes- 
se dadurch unterstützen, dass Informationen den Entscheidungsträgern so 
zur Verfügung gestellt werden, dass sie für diese situativen Entscheidungen 
genutzt werden können. Eine wichtige Frage hierbei ist, welche Informatio- 
nen und formalen Entscheidungsmodelle ein Entscheidungsträger benötigt, 
um eine Entscheidung möglichst gut treffen zu können. Dies wird der Ent- 
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scheidungsträger in der Regel situativ (allein) festlegend Das IM kann dabei 
dem Entscheidungsträger die Entscheidung nicht abnehmen, sondern hat ihn 
in die Lage zu versetzen, sich Informationen und Entscheidungsmodelle über 
entsprechende IKS zu beschaffen. 

Das IM hat hier die Aufgabe, eine Informationsbasis zur Verfügung zu 
stellen, aus der sich der Entscheidungsträger seine benötigten Informationen 
beschafft. Dabei stellt sich die Frage, woher diese Informationen kommen. 
Müssen sie erst erzeugt werden (z. B. durch Auswertung der Absatzzahlen 
der Vergangenheit) oder liegen sie bereits im Unternehmen vor, und wenn, 
dann wo und in welcher Form? Daraus ergibt sich die Frage, wie der Entschei- 
dungsträger an die vorhandenen Informationen gelangt (z. B. unter Nutzung 
von Informationssystemen), d.h. wie sie ihm (möglichst effizient) bereitge- 
stellt werden. 

Aufgrund dieser (insbesondere hinsichtlich der für die Bereitstellung der 
Informationen verwendeten Informationssysteme) engen Beziehung des In- 
formationsmanagements zur Wirtschaftsinformatik wird das IM in diesem 
Kapitel behandelt. Hierzu klären wir zunächst wesentliche Begriffe und stel- 
len ein Ebenenmodell zur Strukturierung der Aufgaben des IM vor; vgl. Ab- 
schnitt 3.2.^ In den weiteren Abschnitten werden dann einige dieser Aufgaben 
diskutiert. 



3.1 Grundlagen 

In diesem Abschnitt sollen die grundlegenden Begriffe im Umfeld des IM 
geklärt werden. Einerseits wird der oben angegebene Begriff des Informa- 
tionsmanagements näher diskutiert, andererseits werden die Bedeutung der 
Begriffe Daten, Information und Wissen und ihre Beziehungen zueinander 
erläutert. 



3.1.1 Begriff des Informationsmanagements 

Zum Informationsmanagement gibt es verschiedene Definitionsansätze, die 
sich insbesondere hinsichtlich der Schwerpunktsetzung innerhalb der zum IM 
gehörenden Aufgaben(gebiete) unterscheiden. Oftmals wird der Schwerpunkt 

^ Informationen sind in der Regel jedoch nur teilweise vorhanden, so dass die Be- 
schaffung der für eine möglichst gute Entscheidung notwendigen Informationen 
das eigentliche Problem des Entscheidens darstellt; vgl. Hayek (1945). Bezüglich 
des individuellen Suchverhaltens nach Informationen kann dabei davon ausgegan- 
gen werden, dass dieses - und damit die Qualität des Ergebnisses der Suche - 
maßgeblich durch die Unbequemlichkeit der Informationsbeschaffung bestimmt 
wird. 

^ Eine ausführlichere und weiterführende Darstellung dieses Themas, die als Basis 
für dieses Kapitel gedient hat, ündet man in Voß und Gutenschwager (2001). 
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des Informationsmanagements auf das Management des Technikressourcen- 
einsatzes, und somit das Management der Datenverarbeitung (DV), gelegt. 

Ein derartiger Ansatz stammt von Heinrich (2002), S. 8: „Mit dem Kon- 
strukt Informationsmanagement wird also das Leitungshandeln (Manage- 
ment) in einem Unternehmen in bezug auf Information und Kommunika- 
tion bezeichnet, folglich alle Führungsaufgaben, die sich mit Information 
und Kommunikation im Unternehmen befassen.“ Darüber hinaus spezifiziert 
Heinrich die Aufgaben des Informationsmanagements wie folgt: Das generel- 
le Sachziel des Informationsmanagements ist es, das Leistungspotential der 
Informationsfunktion (Aufgaben eines Unternehmens, welche sich mit Infor- 
mation und Kommunikation befassen) für die Erreichung der strategischen 
Ziele der Organisation zu bestimmen und dieses durch die Bereitstellung 
einer geeigneten Informationsinfrastruktur (Einrichtungen, Mittel und Maß- 
nahmen zur Produktion, Verbreitung und Nutzung von Informationen im 
Unternehmen; z. B. die technische Infrastruktur) nutzbar zu machen. 

Demgegenüber vertreten einige Autoren die Meinung, Informationsma- 
nagement ist „der Teil der Unternehmensführung, der für das Erkennen und 
Umsetzen der Potentiale der Informationstechnik in Lösungen verantwortlich 
ist“ (siehe Brenner (1994), S. 5, sowie Österle (1987)). Diese Definition betont 
sehr stark die strategischen Aufgaben des Informationsmanagements und der 
Informationstechnik . 

In beiden Ansätzen wird jedoch z.B. die Frage, welche Informationen in 
welcher Form für Entscheidungen benötigt werden, nicht stark genug berück- 
sichtigt. Aus diesem Grund gehen wir von der bereits am Anfang des Kapitels 
angegebenen Definition aus, die betriebliche Entscheidungen beziehungsweise 
Entscheidungsprozesse explizit einbezieht. 

Unter einer Entscheidung versteht man einen kognitiven Prozess mit dem 
Ziel einer Auswahl und Realisierung einer Handlungsalternative aus mindes- 
tens zweien. Grundlage von Entscheidungen sind Informationen, vor allem 
über die Ausgangssituation, die Handlungsalternativen und deren Nutzen 
bzw. Auswirkungen unter Berücksichtigung möglicher Risiken. 

Insbesondere die vollständige und sichere Vorhersage von Ereignissen, die 
in der Zukunft liegen, ist oftmals nicht möglich, d. h. Informationen über 
die (zukünftigen) Auswirkungen einzelner Alternativen können unvollständig 
sein oder auch vollkommen fehlen. Darüber hinaus können Auswirkungen von 
weiteren (äußeren) Einflüssen abhängen, für die sich unmittelbar keine Ein- 
trittswahrscheinlichkeiten angeben lassen (z.B. für Änderungen von Gesetzen 
oder Verordnungen). 

Zudem ist das Entscheidungsproblem generell weiter zu fassen. Möchte ei- 
ne Abteilung eines Unternehmens beispielsweise einen neuen Drucker kaufen, 
so müsste für die Schaffung einer vollständigen Informationsbasis zu allen 
Alternativen ein Mitarbeiter bei sämtlichen möglichen Händlern nachfragen. 
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zu welchem Preis das gewünschte Gerät dort verkauft wird.^ Die Kosten für 
die Beschaffung dieser Informationen (Arbeitszeit des Mitarbeiters, Kosten 
für Telefonate usw.) würden allerdings astronomische Summen erreichen, die 
in keinem wirtschaftlich sinnvollen Verhältnis zum möglichen Nutzen stehen. 
Derartige Transaktionskosten^ müssen daher bei der Entscheidungsfindung 
berücksichtigt werden. Hierzu ist im Verlauf der Informationsbeschaffung zu 
klären, ob es wirtschaftlich sinnvoll ist, weitere Informationen einzuholen. 

Übergeordnetes Ziel des IM ist demzufolge die (wirtschaftliche) effiziente 
Unterstützung von Entscheidungen und Entscheidungsprozessen durch eine 
geeignete Informationsbereitstellung. Darüber hinaus können aus der Defini- 
tion des Informationsmanagements weitere Ziele abgeleitet werden (vgl. Voß 
und Gutenschwager (2001)): 

• Minimierung der Transaktionskosten durch effiziente Gestaltung aller 
Informations- und Kommunikationsaktivitäten, 

• Aufhebung von Informationsasymmetrien (unterschiedliche Personen be- 
sitzen unterschiedliche Informationen) innerhalb eines Unternehmens, 

• Schaffung von Informationsvorsprüngen gegenüber Wettbewerbern sowie 

• Gestaltung der Datenhaltung im Hinblick auf Informationssysteme und die 
Bereitstellung von Lösungsverfahren, z.B. in entscheidungsunterstützen- 
den Systemen. 

3.1.2 Daten, Information und Wissen 

Neben dem Begriff Information werden in ähnlichem Zusammenhang oft auch 
die Begriffe Daten und Wissen verwendet. Die Beziehungen zwischen diesen 
Begriffen sind in Abbildung 3.1 dargestellt. 

„Daten sind Zeichen oder kontinuierliche Funktionen, die aufgrund 
von bekannten oder unterstellten Abmachungen oder vorrangig zum 
Zwecke der Verarbeitung Informationen darstellen.“ (Deutsche In- 
dustrienorm (DIN) 44300) 

Unter Daten versteht man demnach eine Folge von Zeichen, über deren Be- 
deutung weitestgehend Konsens besteht, d. h. die verstanden und prinzipiell 
von einer Person aufgenommen werden können. Daten entsprechen Zeichen- 
folgen, die durch Aggregation und Interpretation in einem Kontext (z. B. über 
Godes, die Zeichen Bedeutungen zuordnen) zu Informationen werden. 

® Und selbst eine Preisagentur sowie intelligente Multiagentensysteme mögen an 
dieser Stelle Probleme haben, eine vollständige Informationsbasis herzustellen. 

^ Transaktionskosten sind im Allgemeinen Kosten, die durch die Koordination 
wirtschaftlicher Aktivitäten entstehen, und bezeichnen im Rahmen von Ent- 
scheidungsprozessen somit die Kosten der Kommunikation und Information; vgl. 
Coase (1979) sowie Picot et al. (2003). 
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Abbildung 3.1. Informationspyramide 



Der Begriff Information ist in Wissenschaft und Praxis nicht einheitlich 
definiert.® Grundlage dieses Kapitels ist der Ansatz, Information als Kennt- 
nis von Sachverhalten aufzufassen. Demgegenüber versteht man unter Wis- 
sen die Kenntnis von Zusammenhängen (Mustern). Um Zusammenhänge zu 
erkennen, ist eine Verarbeitung von Informationen erforderlich. Somit ent- 
steht durch Verarbeiten und Verstehen von Informationen in einem gewissen 
Kontext neues Wissen. Diesen Prozess der Einordnung von Informationen 
in Wissen bzw. der Erweiterung von Wissen durch Informationen bezeichnet 
man auch als Lernen. 

Hieraus ergibt sich die folgende, insbesondere im Zusammenhang mit der 
Entscheidungsunterstützung sinnvolle, Abgrenzung der Begriffe Information 
und Wissen: 

„Information ist ein immaterielles Gut, das dazu dient, zweckorien- 
tiertes Wissen zu bilden. [. . .] der Zweck von Wissen besteht in der 
Vorbereitung und Durchführung von Handlungen und Entscheidun- 
gen.“ (Voß und Gutenschwager (2001), S. 24) 

Informationen bilden somit die Grundlage für Entscheidungen, da aus 
ihnen Wissen entstehen kann, ohne das Entscheidungsprozesse undenkbar 
sind.® 

Beispielsweise werden im Rahmen der Produktionsplanung eines Un- 
ternehmens für eine Absatzprognose Absatzzahlen aus der Vergangenheit 
benötigt. Liegen diese Zahlen z. B. auf einem elektronischen Speichermedi- 
um (Festplatte o.A.) vor, dann sind die dort gespeicherten Zeichen Daten. 

® Eine Aufstellung verschiedener Definitionsansätze ist u. a. in Maier und Lehner 
(1995) zu finden. Für betriebswirtschaftliche Fragestellungen ist auch der folgen- 
de nutzenorientierte Informationsbegriff verhreitet: „Information ist zweckorien- 
tiertes Wissen, also solches Wissen, das zur Erreichung eines Zweckes, nämlich 
einer möglichst vollkommenen Disposition eingesetzt wird.“ (Wittmann (1959), 
S. 14) 

® Zur Vertiefung der Begriffe Information und Wissen aus betriebswirtschaftlicher 
Sicht siehe z. B. Bode (1997). 
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Aus diesen Daten können durch Interpretation Informationen gewonnen wer- 
den (z. B. die Information, welche Menge eines Produktes in einem gewissen 
Zeitraum verkauft wurde). Das heißt, Daten werden zu Informationen, wenn 
sie für eine Person einen potenziellen Nutzen haben, weshalb oftmals der 
Begriff Daten im Sinne von Information verwendet wird. Durch eine Ver- 
knüpfung mehrerer Informationen kann dann Wissen erzeugt werden. Zum 
Beispiel kann der Entscheidungsträger durch die Überprüfung aller Absatz- 
zahlen eines Produktes über einen längeren Zeitraum erkennen, ob im Laufe 
der Zeit mehr oder weniger Produkte verkauft wurden oder ob es z. B. einen 
saisonalen Zusammenhang zwischen den Absatzzahlen gibt. Das hierdurch 
erworbene Wissen des Entscheidungsträgers kann er dann im Entscheidungs- 
prozess nutzen. 

Mit Hilfe von Wissen wiederum können aus (bekannten) Informationen 
neue Informationen gewonnen werden. So kann aus dem Wissen, dass der 
Absatz eines Produktes in letzter Zeit jeden Monat um 5 % gestiegen ist, 
und der Information, dass in diesem Monat 1000 Produkte verkauft wur- 
den, im Idealfall gefolgert werden, dass im nächsten Monat ungefähr 1050 
Produkte verkauft werden können. Diese (neu erzeugte) Information dient 
dann als Basis für die Entscheidung über die zu fertigende Menge des Pro- 
duktes. Aus Informationen entstehen wiederum Daten durch eine Codierung 
der Informationen, d. h. die Daten stellen eine technische Repräsentation der 
Informationen dar. Die Zahl 1050 ist dann z. B. ein entsprechendes (neues) 
Datum. 

Aus obiger Definition für Information wird deutlich, dass Information 
als immaterielles Gut betrachtet wird. Das Gut Information zeichnet sich ge- 
genüber anderen Gütern u. a. dadurch aus, dass es nicht „besichtigt“ (bzw. be- 
gutachtet) werden kann. Begutachtet ein Mensch eine Information, dann muss 
er dazu die Information aufnehmen und verarbeiten, womit sie zwangsläufig 
in seinen Besitz übergeht. Folglich kann man den genauen Wert einer Informa- 
tion häufig erst dann bestimmen, wenn man sie erhalten hat {Informations- 
paradoxon) . So können Sie als Leser dieses Buches seinen (für Sie hoffentlich 
großen) Wert vermutlich erst einschätzen, nachdem Sie zumindest einen Teil 
des Buches gelesen haben und Sie dadurch die darin enthaltenen Informatio- 
nen besitzen. Ein Ex-ante-Kalkül über das Kosten-Nutzen- Verhältnis einer 
Information ist somit oftmals nur bedingt möglich, da zwar die Kosten für die 
Informationsbeschaffung im Vorhinein bestimmbar sein können, der Nutzen 
jedoch meistens nur geschätzt werden kann oder eine derartige Abschätzung 
teilweise sogar unmöglich ist. 

Zusätzlich besteht das Problem, dass der Nutzen einer Information indivi- 
duell unterschiedlich sein kann. Einerseits kann einer Person eine Information 
bereits bekannt sein, so dass ein nochmaliges Erlangen dieser Information kei- 
nen Nutzen beinhaltet. Auf der anderen Seite können verschiedene Personen 
die Zweckmäßigkeit (den Nutzen) einer Information unterschiedlich bewerten, 
z.B. weil sie nicht über dasselbe Vor wissen verfügen und somit einen unter- 
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schiedlichen Wissenszuwachs durch diese Information erzielen können. Sollen 
Informationen als Grundlage für Entscheidungen dienen, darf daher der Ent- 
scheidungsträger nicht außer Acht gelassen werden, d. h. es müssen die Infor- 
mationen bereitgestellt werden, die dem Entscheidungsträger am meisten für 
seine Entscheidung nützen. 

Neben dem Inhalt der Information ist auch ihre Form von Bedeutung, 
da die Verarbeitung von Informationen auch hiervon abhängt. So wird hin- 
sichtlich der Prognose von Absatzzahlen eine Tabelle dieser Werte für den 
Entscheidungsträger einen größeren Nutzen besitzen als ein Text, in dem 
die Absatzzahlen unstrukturiert enthalten sind, da er sich in diesem Fall die 
Zahlen erst aus dem Text heraussuchen muss. Die (für den Entscheidungs- 
prozess) geeignetste Form bestimmt der Entscheidungsträger in der Regel 
selbst, da nur er weiß, welche Form die Information besitzen sollte, damit er 
sie am besten verarbeiten (und nutzen) kann. Diese Festlegung kann nicht 
pauschal für alle Entscheidungen, sondern nur situativ (abhängig von der 
konkreten Entscheidungssituation und dem Entscheidungsträger) getroffen 
werden. Das IM hat somit die Aufgabe, individuell und situativ auftretenden 
Informationsnachfragen mit einem entsprechend flexibel gestalteten Informa- 
tionsangebot zu begegnen, woraus sich entsprechende Anforderungen an die 
für die Informationsbereitstellung verwendeten IKS ergeben. 



3.2 Ebenenmodell des Informationsmanagements 

Die Art und die Güte der Bereitstellung von Informationen hängt wesent- 
lich von den Funktionalitäten und der Ausgestaltung der dafür verwendeten 
Informations- und Kommunikationssysteme ab. Daher muss das IM Anforde- 
rungen an die IKS definieren. Darüber hinaus ergeben sich auch Anforderun- 
gen an die den IKS zu Grunde liegende Infrastruktur (Rechner, Netze, Sys- 
temsoftware u. A.), z.B. hinsichtlich benötigter Bandbreiten des Netzwerkes 
oder der Rechnerleistung. Hieraus ergibt sich eine sinnvolle Unterscheidung 
der Aufgaben hinsichtlich der Nähe zur Informationstechnik, wie sie u. a. bei 
Krcmar (2003), Wollnik (1988) sowie Voß und Gutenschwager (2001) zu fin- 
den ist. Durch diese Unterteilung entstehen drei Ebenen des Informationsma- 
nagements, die in Abbildung 3.2 dargestellt sind. Jede dieser Ebenen definiert 
eigene Aufgabenfelder und damit unterschiedliche Leistungs- und Wissensan- 
forderungen. Gleichzeitig stellen die einzelnen Ebenen Anforderungen an die 
jeweils darunter liegende und bieten Unterstützungsleistungen für die jeweils 
übergeordnete Ebene an. 

In der oberen Ebene stehen die für die Entscheidungsfindung und Prob- 
lemlösung erforderlichen Informationen im Mittelpunkt. Zu dieser Ebene 
gehören alle Aufgabengebiete, die direkt mit Informationen im Zusammen- 
hang stehen. Dies beinhaltet insbesondere die Fragen, wer welche Informatio- 
nen benötigt (d. h. die Informationsbedarfsanalyse) und wie diese dem Nutzer 
bereitgestellt werden (d. h. die Planung ihrer Bereitstellung). 




70 



3. Informationsmanagement 




Abbildung 3.2. Ebenenmodell des Informationsmanagements; nach WoIInik 
(1988), S. 38 



Hieraus ergeben sich dann Anforderungen an die darunter liegende Ebene, 
deren Gegenstand Informations- und Kommunikationssysteme, insbesondere 
Anwendungssysteme zur Unterstützung der Informationsbedarfsanalyse und 
-bereitstellung, sind. Ausgehend von den Anforderungen wird hier z.B. fest- 
gelegt, welche IKS eingesetzt werden. Alle Aufgaben, die sich hieraus ergeben 
(Installation, Updates, Benutzerschulung usw.), können ebenfalls dieser Ebe- 
ne zugerechnet werden. Darüber hinaus gehört zu dieser Ebene auch das 
Datenmanagement, d.h. die Verwaltung der im Unternehmen anfallenden 
und benötigten Daten. Ausgehend von den einzusetzenden IKS ergeben sich 
Anforderungen an die für ihren Einsatz notwendige Infrastruktur (Rechner, 
Netzwerk, Systemsoftware u. A.), die Gegenstand der untersten Ebene ist. 

Neben der Untergliederung des Informationsmanagements hinsichtlich der 
Nähe zur Informationstechnik lassen sich noch weitere Betrachtungsebenen 
(Dimensionen) unterscheiden. So kann eine Differenzierung bezüglich der 
Fristigkeit (lang-, mittel- oder kurzfristig) der Aufgaben erfolgen, woraus 
sich strategische, taktische (administrative) bzw. operative Aufgabenfelder 
ergeben. Diese Betrachtungsweise besitzt in der Betriebswirtschaftslehre ei- 
ne große Verbreitung und wird deshalb teilweise auch für das Informati- 
onsmanagement verwendet; vgl. Heinrich (2002). Darüber hinaus ist eine 
Unterscheidung in internes und externes Informationsmanagement möglich. 
Während die oben dargestellte Sichtweise des IM eher unternehmensinterner 
Natur ist, steht beim externen Informationsmanagement („kundenorientier- 
tes Informationsmanagement“) der Informationsaustausch mit den externen 
Partnern (z. B. Lieferanten) bzw. Kunden des Unternehmens im Mittelpunkt. 

Eine Übersicht über die Aufgaben des Informationsmanagements und de- 
ren Einordnung in das Ebenenmodell findet sich in Abbildung 3.3. Zusätzlich 
zu den dort aufgeführten können weitere, ebenenübergreifende Aufgabenge- 
biete angegeben werden; vgl. Krcmar (2003). Hierzu zählen 

• die Organisation des IM (d. h. Verankerung im Unternehmen und gegebe- 
nenfalls Aufbauorganisation der IM- Abteilung), 
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• durch die Informationsverarbeitung induzierte organisatorische Verände- 
rungen (als Bestimmung der Bedeutung des IM für das Unternehmen und 
die Unternehmensstrategie), 

• das Personalmanagement des IM sowie 

• das Controlling der Informationsverarbeitung (als Steuerung des IM). 



Ebene des 
Informations- 
einsatzes 
(IM im 
engeren 
Sinne) 



Ebene der 
Informations- 
lind Kommu- 
nikations- 
systeme 



Ebene der 
Informations- 
und Kommu- 
nikations- 
infrastruktur 



Informationsfluss im individueller 

Bedarf ► B 

1 


Entscheidungsprozes 
eschaffung ► Ver 


$ 

arbeitung — ► B 


sreitstellung 




Informationsplanung: 
Infomationsbedarfsanalyse, 
Planung der Informations- 
bereitstellung 












Anforderungen bezüglich 
Informationsbeschaffung, 
-Verarbeitung, -bereitstellung 


Reportgenerierung, 
Verfahren zur 
Suche in 
Datenbanken, 
Kommunikation 


explizite Ent- 
scheidungs- 
modelle und 
Methoden (z.B. 
Data Mining) 


Kommunikation, 
Ablagemöglich- 
keiten (z.B. im Rah- 
men des Wissens- 
managements) 



Applikationen aus den Bereichen der Suche in Daten- 
banken, entscheidungsunterstützende sowie wissens- 
basierte Systeme, Groupware, Workflow Management 

it it it 

Datenbanken (formatierte und unformatierte) 




• Informationssystemstrategie 

• Softwareentwicklung, 
-einkauf, -anpassung, 
-Wartung und -pflege 

• Datenmanagement 

• Systemeinführung, Schulung, 
Benutzerbetreuung 



Abbildung 3.3. Aufgaben des Informationsmanagements; in Anlehnung an Voß 
und Gutenschwager (2001), S. 74 



Das Controlling der Informationsverarbeitung (IV) beinhaltet im Wesent- 
lichen die Steuerung und Kontrolle der Aufgaben des IM und betrifft dadurch 
alle drei Ebenen.^ Die wesentlichen Ziele des IV-Controllings sind zum einen 
die Verbesserung der Wirtschaftlichkeit (Effizienz) sowie der Effektivität des 
IM, der IKS und deren Infrastruktur und zum anderen die Sicherstellung der 
Qualität und Funktionalität der IKS bzw. IT sowie die Einhaltung von Ter- 
minen. Das IV-Controlling kann hinsichtlich der Entwicklung und Umsetzung 

Zum IV-Controlling vgl. u. a. Krcmar (2003) sowie die Beiträge in Krcmar et al. 

( 2000 ). 
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der IT-Strategie, der Softwareentwicklung sowie des IT-Betriebes unterglie- 
dert werden. Der mittlere Bereich umfasst somit auch das Projektcontrolling 
von Softwareprojekten; vgl. Abschnitt 6.3.2. 

Innerhalb des IV-Controllings können verschiedene Verfahren und Metho- 
den zum Einsatz kommen: 

• Analysetechniken und Entscheidungshilfen der strategischen IV-Planung 
(z. B. Portfolioanalysen), 

• Methoden zur Bewertung und Entscheidung (Kosten-Nutzen-Analyse, 
Kosten- und Leistungsrechnung u. A.), 

• Methoden der Projektplanung und -kontrolle (z. B. Netzplantechnik, Auf- 
wandsschätzverfahren; vgl. Abschnitt 6.3.3), 

• Werkzeuge zur Qualitätsprüfung (vgl. Abschnitt 6.1.7), 

• Methoden zur Leistungsmessung und Verbesserung der IV-Infrastruktur 
(u. a. mittels Benchmarking), 

• Berichtswesen, Dokumentation und Dokumentationssysteme. 

Ausgehend von den Aufgaben des IM lässt sich insbesondere in der mitt- 
leren Ebene eine große Nähe zur Wirtschaftsinformatik feststellen. So sind 
Entwicklung, Einkauf und Anpassung sowie Wartung und Pflege von Software 
zur Unterstützung der Informationsbereitstellung auch essenzielle Bestand- 
teile der Wirtschaftsinformatik. Eine klare Zuordnung dieser Aufgaben zum 
IM oder zur Wirtschaftsinformatik ist somit schwierig. Eine mögliche Ab- 
grenzung besteht darin, dem Informationsmanagement der unteren beiden 
Ebenen vor allem die Entwicklung der Strategie der IKS (bzw. der IT) sowie 
die Planung, Steuerung und Kontrolle der Umsetzung dieser Strategie (und 
somit das Controlling der IKS und IT) zuzuordnen. Die eigentliche Umset- 
zung der Strategie hinsichtlich konkreter Informations- bzw. Anwendungs- 
systeme obliegt dann der Wirtschaftsinformatik. Dies bedeutet, dass das IM 
ausgehend von den betrieblichen Entscheidungen und den dafür benötigten 
Informationen Anforderungen an die für die Informationsversorgung verwen- 
deten IKS und somit an die Wirtschaftsinformatik definiert. Die Ableitung 
dieser Anforderungen mittels der Informationsbedarfsanalyse und der Infor- 
mationsplanung ist dagegen wesentlicher Bestandteil des IM und gehört nicht 
zur Wirtschaftsinformatik. 

Eine Diskussion der Aufgaben der einzelnen Ebenen findet sich in den 
Abschnitten 3.3 bis 3.5.® In Abschnitt 3.6 gehen wir dann auf die ebenenüber- 
greifenden Aufgaben der durch die Informationsverarbeitung induzierten or- 
ganisatorischen Veränderungen ein. 



Für eine umfassendere Darstellung der Aufgaben der unteren beiden Ebenen 
wird neben Voß und Gutenschwager (2001) auf Heinrich (2002) verwiesen. 
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3.3 Management des Informationseinsatzes 

Die Ebene des Informationseinsatzes umfasst u. a. alle Aufgaben, die der Kon- 
zeption der darunter liegenden Ebenen dienen. Hierzu gehören vor allem die 
Analyse des Informationsbedarfes und die Planung der Informationsbeschaf- 
fung und -bereitstellung. Darüber hinaus beinhaltet dies auch die Aufgaben, 
die auf Informations- und Kommunikationssystemen aufsetzen. Insbesondere 
die Suche in bzw. die Auswertung von Datenbeständen und das Wissensma- 
nagement gehören zu diesen Aufgabenfeldern. Ziel ist die Unterstützung der 
Entscheidungsträger bei der Deckung von Informationsangebot und (indivi- 
dueller) -nachfrage, d. h. die Versorgung der Entscheidungsträger mit den für 
die Willensbildung relevanten Informationen. 

3.3.1 Informationsplanung 

Wie in Abbildung 3.3 verdeutlicht ist, umfasst der Informationseinsatz im 
(individuellen) Entscheidungsprozess ausgehend vom Informationsbedarf die 
Beschaffung, Verarbeitung und Bereitstellung von Informationen. Dieser In- 
formationseinsatz kann durch das IM mittels einer Informationsplanung un- 
terstützt werden. Diese beinhaltet die Analyse des (potenziellen) Informa- 
tionsbedarfes der Entscheidungsträger sowie die Planung der Bereitstellung 
dieser Informationen. 

Somit entsteht ein zweistufiger Prozess, wobei das IM übergeordnet für 
alle Entscheidungsträger im Unternehmen eine Ermittlung der potenziellen 
Informationsbedarfe durchführt und darauf aufbauend diese Informationen 
aus diversen (auch externen) Quellen beschafft bzw. die Beschaffung steuert 
und sie (z. B. in IKS) geeignet bereitstellt, wodurch ein Informationsangebot 
entsteht. Diese Informationsbereitstellung geschieht in zwei Schritten. Zuerst 
erfolgt eine Allokation der Informationen, d. h. eine Zuordnung der Informa- 
tionen zu den einzelnen Nachfragern (bzw. den IKS, in denen sie abgelegt 
werden sollen). Daran schließt sich die Distribution der Informationen an. 
In diesem Schritt muss die Art der Informationsverteilung geklärt werden, 
d.h. die Informationskanäle und -wege sowie die Informationsmittel (z.B. 
technische Ressourcen) müssen definiert werden. 

Hierbei stellt sich das Problem, die richtige Information zum richtigen 
Zeitpunkt am richtigen Ort zu den richtigen Kosten bereitzustellen. Diese 
Forderung entspricht dem Grundprinzip der Informationslogistik, worunter 
die Logistik der Wirtschaftsware Information und demnach Transport und 
Bereitstellung (also Distribution und Allokation) von Informationen verstan- 
den wird; vgl. Hansen und Peschanel (1996) und Voß und Domschke (1999). 
Die Vorgabe der „richtigen Information“ bedeutet, dass genau die angefor- 
derte Information in der gewünschten Qualität (z. B. als Graphik aufbereitet 
oder in einem vorgegebenen, zur Weiterverarbeitung geeigneten Dateiformat) 
bereitgestellt werden soll. 
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Des Weiteren verdeutlicht dieses Grundprinzip, dass auch im Rahmen 
der Informationsbereitstellung der Kostenaspekt nicht vernachlässigt werden 
darf. Folglich besteht eine Aufgabe der Informationsbereitstellung im Auf- 
bau einer geeigneten Informationsdistribution, mit deren Hilfe Informationen 
kostengünstig verteilt werden können. Grundvoraussetzung für eine effiziente 
Informationsbereitstellung sind die Transparenz der Informations- und Kom- 
munikationsstrukturen, der Organisationsstrukturen, der Datenbestände und 
der Informationssysteme, die durch eine Unternehmensmodellierung (vgl. Ab- 
schnitt 4.1) gewonnen werden kann. 

Unabhängig von der Allokation der Informationen und dem Distributi- 
onsnetzwerk muss jeder Entscheidungsträger für die von ihm zu treffenden 
Entscheidungen seinen Informationsbedarf (situativ) ermitteln und sich die- 
se Informationen aus dem vom IM aufgebauten Angebot (und gegebenenfalls 
weiteren Quellen) beschaffen. Dies entspricht der zweiten Stufe des oben an- 
gesprochenen Prozesses. 

Durch die Verarbeitung dieser Informationen im Entscheidungsprozess 
können neue Informationen (z. B. das Ergebnis des Entscheidungsprozesses) 
entstehen, die der Entscheidungsträger dem Angebot hinzufügen (d. h. für 
andere Entscheidungsträger bereitstellen) kann. 

Kehren wir zum ersten Schritt, der übergeordneten Informationsplanung, 
zurück. Um dem Entscheidungsträger die „richtigen“ Informationen bereit- 
zustellen, muss zuerst sein (voraussichtlicher) Informationsbedarf bestimmt 
werden. Man kann folgende Unterscheidung verschiedener Informationsbe- 
darfe vornehmen: 

• (objektiver) Informationsbedarf: Der (objektive) Informationsbedarf wird 
als die Art, Menge und Beschaffenheit von Informationen verstanden, die 
ein Individuum oder eine Gruppe zur Erfüllung einer Aufgabe benötigt 
(vgl. Picot (1988), S. 236), und ist aus einer Sachaufgabe ableitbar. 

• subjektiver Informationsbedarf: Unter subjektivem Informationsbedarf 
verstehen wir diejenigen Informationen (ebenfalls charakterisiert durch 
Art, Menge und Beschaffenheit), von denen der Entscheidungsträger der 
Meinung ist, dass er sie zur Erfüllung der Aufgabe benötigt. 

• nachgefragter (geäußerter) Informationsbedarf: Von den subjektiv benötig- 
ten Informationen wird ein Entscheidungsträger im Allgemeinen nicht alle 
Informationen nachfragen, so z.B. die seiner Meinung nach eher unwich- 
tigen. Die Informationsnachfrage umfasst daher den Teil des subjektiven 
Informationsbedarfes, den der Entscheidungsträger tatsächlich nachfragt. 

Dem Bedarf gegenüber steht das Informationsangebot, das alle im Unter- 
nehmen vorhandenen Informationen umfasst. Durch Nutzung dieses Angebo- 
tes verschafft sich der Entscheidungsträger einen Informationsstand, der aus 
denjenigen Informationen des Angebotes besteht, die für die Erfüllung der 
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Aufgabe (objektiv) nötig sind und nachgefragt werden; vgl. Abbildung 3.4. 
Da nur der Informationsstand des Entscheidungsträgers (und nicht das insge- 
samt vorhandene Angebot) Einfluss auf die Qualität einer Entscheidung hat, 
ist es nicht sinnvoll, dem Entscheidungsträger alle möglichen Informationen 
(oder sogar alle Daten) anzubieten.® 




Abbildung 3.4. Ermittlung des Informationsstandes aus Bedarf, Angebot und 
Nachfrage 



Bei der Analyse und Ermittlung des Informationsbedarfes sind neben dem 
Informationsgehalt (d. h. der Frage, was benötigt wird) weitere Dimensionen 
zu berücksichtigen (vgl. Bode (1993)): 

• die Darstellungsform der Information (In welcher Form wird die Informa- 
tion benötigt?), 

• der Zeitaspekt (Wann wird die Information benötigt?), 

• der Kontext (Wofür wird die Information benötigt?). 

Zur Ermittlung des Informationsbedarfes stehen mehrere Verfahren zur 
Verfügung. Bei subjektiven Verfahren wird der Informationsbedarf aus An- 
gaben der betroffenen Personen (Entscheidungsträger) bestimmt (z. B. mit 
Hilfe von offenen Befragungen, Befragungen der Mitarbeiter im Tätigkeits- 
umfeld sowie Wunschkatalogen). Die Qualität des so ermittelten Informa- 
tionsbedarfes hängt sehr stark von den befragten Personen ab, so dass die 
Gefahr besteht, nur den subjektiven Informationsbedarf zu ermitteln. 

Objektive, analytische Verfahren versuchen, den objektiven Informations- 
bedarf direkt aus den Aufgaben und anderen allgemeingültigen Vorgaben zu 
gewinnen (z.B. die Strategieanalyse, d.h. Ableitung des Informationsbedar- 
fes aus den strategischen Zielen des Unternehmens, oder die Prozessanalyse 
basierend auf der Unternehmensmodellierung) . Bei komplexen oder erstmals 
auftretenden Problemen ist die Ermittlung des objektiven Bedarfes jedoch 
sehr schwierig und oftmals überhaupt nicht möglich. 

® Hierdurch könnte eine Informationsproliferation, d. h. eine für den Entschei- 
dungsträger schwer überschaubare Informationsflut, entstehen. 
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Darüber hinaus können die beiden Verfahrenstypen kombiniert werden, 
d. h. es werden so genannte gemischte Verfahren verwendet. Ein Beispiel 
hierfür ist die Methode der kritischen Erfolgsfaktoren (vgl. Rockart (1979)), 
bei der Befragungen auf einige zentrale Faktoren, die für den Unternehmens- 
erfolg eine besonders große Bedeutung besitzen, abgestimmt werden. Dadurch 
werden die Befragungen auf diese kritischen Erfolgsfaktoren fokussiert, womit 
die Gefahr einer völlig subjektiven Einschätzung von Informationsbedarfen 
vermindert wird. 

Soll eine Informationsbedarfsanalyse und -ermittlung für viele Personen 
(z.B. ein gesamtes Unternehmen) durchgeführt werden, dann ist davon aus- 
zugehen, dass zum einen bereits ein Informationsangebot vorhandenen ist 
und es zum anderen in den seltensten Fällen wirtschaftlich ist, alle Infor- 
mationsbedarfe gleichzeitig zu ermitteln. Aus diesem Grund sollte vor der 
eigentlichen Informationsbedarfsanalyse eine Priorisierung ihrer Einsatzfel- 
der erfolgen, d.h. es muss (z.B. in Abhängigkeit von der Dringlichkeit oder 
der vorhandenen Informationsangebote) bestimmt werden, in welcher Rei- 
henfolge die verschiedenen (Unternehmens-)Bereiche hinsichtlich ihres Infor- 
mationsbedarfes analysiert werden sollen; vgl. z.B. Voß und Gutenschwager 
( 2001 ). 

An die Informationsbedarfsermittlung schließt sich die Informationshe- 
schaffung an, die in einem Zweistufenmodell erfolgen kann. Im ersten Schritt 
steht die Suche nach den Quellen im Vordergrund, d. h. die Frage „Woher 
kann die Information beschafft werden?“ Dabei können sowohl innerbetrieb- 
liche (interne) als auch außerbetriebliche (externe) Informationslieferanten 
(z.B. IKS, aber auch Informationsdienstleister) auftreten. Erst im zweiten 
Schritt erfolgt die eigentliche Gewinnung der Information mittels der zur 
Verfügung stehenden Methoden der Informationsbeschaffung. 

Die Berücksichtigung der Kosten spielt nicht nur innerhalb des zweiten 
Schrittes eine Rolle, sondern bereits vorher, wenn darüber entschieden wird, 
in welchem Umfang die Quellensuche erfolgen soll. So kann zum einen solan- 
ge gesucht werden, bis (mindestens) eine Quelle gefunden worden ist, zum 
anderen besteht jedoch die Möglichkeit, die Suche vorher abzubrechen (z. B. 
wenn die Kosten der Suche und Gewinnung der Information ihren erwarteten 
Nutzen übersteigen). 

3.3.2 Wissensmanagement 

Da Wissen Grundlage jedes wirtschaftlichen Handelns ist, ist auch in Ent- 
scheidungsprozessen Wissen (z. B. in Form von Entscheidungsregeln oder ex- 
plizit formulierten Entscheidungsmodellen) notwendig. Dadurch ergibt sich 
die Forderung, die Entscheidungsträger bei Erwerb, Nutzung und Weitergabe 
von Wissen zu unterstützen. Diese Unterstützungsaktivitäten werden unter 
dem Begriff Wissensmanagement zusammengefasst. Hierbei sind zum einen 
die Verwaltung des (unternehmensinternen) Wissens und zum anderen der 
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Zugriff auf dieses Wissen sowie die explizite Verarbeitung von Informationen 
(als Wissensgenerierung) zu gestalten. 

Vor der Beschäftigung mit den Aufgaben des Wissensmanagements 
scheint es sinnvoll, den Betrachtungsgegenstand „Wissen“ noch einmal 
exemplarisch zu spezifizieren. Wissen existiert oftmals nur implizit in Form 
von unbewusst angewendeten Verhaltensregeln. Wird dieses Wissen artiku- 
liert, d.h. in explizites Wissen umgewandelt, dann entstehen hierdurch In- 
formationen und gegebenenfalls Daten (z. B. Dokumente). Diese können von 
anderen Personen genutzt werden, um das eigene Wissen zu erweitern. Wis- 
sen ist also in der Regel personengebunden, da zur Entstehung von Wissen 
Informationen von einer Person verarbeitet werden müssen; vgl. Abschnitt 
3.1.2. Die Bereitstellung von explizitem Wissen bedeutet demnach die Be- 
reitstellung von Informationen, wodurch ein enger Bezug zwischen Informa- 
tionsplanung und Wissensmanagement offensichtlich wird. 

Neben der Klassifikation von Wissen in explizit und implizit kann eine 
Unterteilung des Wissens in drei Bereiche vorgenommen werden: 

1. Allgemeinwissen 

• kein unmittelbarer Aufgabenbereich 

• in der Regel vollständig präsent 

2. Spezial- und Fachwissen 

• deklaratives Wissen (Was, symbolische Beschreibung) 

• prozedurales Wissen (Wie, Operationen) 

3. Metawissen über den Einsatz des Wissens (Wann) 

Das Wissensmanagement beschäftigt sich vor allem mit Spezial- und Fach- 
wissen. Da dieses oftmals in Form von Dokumenten vorliegt, wird das Doku- 
mentenmanagement (vgl. Abschnitt 7.1.3) häufig als integraler Teil des Wis- 
sensmanagements verstanden. Zum Wissensmanagement gehört jedoch eine 
Vielzahl von Aufgaben, die z.B. gemäß der in Abbildung 3.5 dargestellten 
Bausteine des Wissensmanagements klassifiziert werden können. Diese Bau- 
steine bilden idealerweise einen Kreislauf von der Definition der Wissensziele 
bis zur Bewertung von Wissen. Ausgehend von dieser Bewertung können 
dann neue Ziele definiert werden. Gleichzeitig sind die sechs wesentlichen 
Bausteine, die der Verwirklichung der Ziele dienen, netzförmig miteinander 
gekoppelt, so dass sie in beliebiger Reihenfolge durchgeführt werden können. 

Im Rahmen der Identifikation des vorhandenen Wissens können z. B. 
so genannte Wissenslandkarten erstellt werden, in denen aufgezeigt wird, 
welche Kenntnisse und Fähigkeiten (insbesondere Expertenwissen) einzelne 
Mitarbeiter oder Abteilungen besitzen. Diese Informationen können als eine 
Quelle für die Informationsbeschaffung genutzt werden. Im Rahmen der (un- 
ternehmensinternen) Entwicklung neuen Wissens ist insbesondere eine Un- 
terstützung von Lernprozessen wichtig. Unter Wissens(ver)teilung wird die 
Planung der Distribution und Allokation des Wissens im Unternehmen ver- 
standen. Allerdings muss dabei beachtet werden, dass diese (Ver)teilung nicht 
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Abbildung 3.5. Bausteine des Wissensmanagements; Quelle: Probst et al. (1999), 
S. 58 



nur explizites, sondern auch implizites Wissen betrifft. Der Transfer dieses 
Wissens kann oftmals nur individuell organisiert werden, so dass die Aufgabe 
des Wissensmanagements hier eher in der Schaffung geeigneter organisatori- 
scher Rahmenbedingungen liegt. So kann die wechselnde Zusammensetzung 
von Arbeitsgruppen dazu beitragen, dass Personen ihr Wissen an andere 
weitergeben können, die dieses Wissen bisher nicht besitzen. Die Effektivität 
entsprechender Ansätze hängt dabei auch von der Motivation der so genann- 
ten Experten zur Weitergabe ihres Wissens ab. 

Im Rahmen der Wissensnutzung ist vor allem Wert auf die Unterstützung 
des produktiven Einsatzes von Wissen zu legen, wobei der Motivation von 
Personen, Wissen anderer aufzunehmen und auch zu verwenden, eine große 
Bedeutung zukommt. Wissen, das für andere Personen einen potenziellen 
Nutzen hat, sollte für die Zukunft bewahrt werden. Die Bewahrung von im- 
plizitem Wissen kann z.B. dadurch erfolgen, dass die Personen, die dieses 
Wissen besitzen, dauerhaft in das Unternehmen eingebunden werden. Grund- 
lage einer dauerhaften personenunabhängigen Speicherung von Wissen ist 
letztendlich die Umwandlung von implizitem in explizites Wissen. Sowohl 
im Rahmen der Wissensbewahrung als auch der Wissens(ver)teilung muss 
das Wissensmanagement geeignete Voraussetzungen (Rahmenbedingungen) 
schaffen, damit die Mitarbeiter ihr eigenes Wissen anderen zur Verfügung 
stellen. 

Das Wissensmanagement kann auf vielfältige Weise durch IKS unterstützt 
werden. So können Wissenslandkarten im Rahmen der Informationsplanung 
aufgebaut werden, was mit Hilfe einer geeigneten IT-Unterstützung reali- 
siert werden kann. Für eine Unterstützung von Lernprozessen, Wissenstrans- 
fers und Wissensnutzung in Gruppen finden insbesondere Groupware bzw. 
GSGW-Systeme (GSGW: Gomputer Supported Gooperative Work; vgl. hier- 
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zu Abschnitt 7.1.4) Anwendung. Wissensbasierte Systeme und Expertensys- 
teme können genutzt werden, um Spezial- und Fachwissen in Form explizi- 
ten Wissens anderen Personen zur Verfügung zu stellen, die Nutzung die- 
ses Wissens zu erleichtern und es für die Zukunft zu bewahren. Für der- 
artige Unterstützungsleistungen kommen auch Dokumentationssysteme in 
Frage. Die Wissens(ver)teilung kann darüber hinaus durch Einsatz speziel- 
ler Management-Support-Systeme effizient gestaltet werden; vgl. hierzu Ab- 
schnitt 3.4. 

Eine weitere Möglichkeit zur Unterstützung der Wissensentwicklung bie- 
tet das Data Mining, worunter die automatisierte Analyse von vorhandenen 
Daten mit dem Ziel der Identifikation von (auf den ersten Blick nicht erkenn- 
baren) Zusammenhängen verstanden wird.^*^ So kann bei einer Analyse der 
Auftragsdaten eines Versandhandels z. B. festgestellt werden, dass viele Kun- 
den, die ein bestimmtes Produkt kaufen, auch einen anderen bestimmten Ar- 
tikel bestellen. Um diesen Zusammenhang ohne das Data Mining herauszufin- 
den, müsste für sämtliche Kombinationen von Artikeln überprüft werden, wie 
viele Kunden beide Artikel gekauft haben. Eine solche Auswertung kann ins- 
besondere bei großen Datenmengen kaum ohne geeignete IT-Unterstützung 
(in Form einer Automatisierung) durchgeführt werden. Als Datenbasis hierfür 
sind vor allem strukturierte Daten geeignet, die in einer Datenbank oder ins- 
besondere einem Data Warehouse abgelegt sind; vgl. Kapitel 5. 

Für die Suche nach Zusammenhängen zwischen den Daten können unter- 
schiedliche Verfahren verwendet werden, wozu Methoden der Datenvisuali- 
sierung, der Statistik und Entscheidungsregeln ebenso gehören wie z. B. Me- 
thoden der künstlichen Intelligenz. Die Gewinnung neuer Informationen (und 
die Erzeugung neuen Wissens) durch eine automatisierte Datenanalyse ist je- 
doch nicht nur von der Auswahl des Auswertungsverfahrens, sondern auch 
von der verwendeten Datenbasis (hinsichtlich z.B. Menge, Redundanz und 
Komplexität) und der abschließenden Interpretation der Ergebnisse der Aus- 
wertung abhängig. Diese Interpretation kann nicht automatisiert erfolgen, 
sondern muss von der einzelnen Person durchgeführt werden. Data Mining 
kann demnach nur eine Unterstützung des Erkennens von Informationen und 
des Lernprozesses bieten. Das Lernen selbst kann dem Menschen hierdurch 
nicht abgenommen werden, d.h. es lassen sich nur Teilschritte des Lernpro- 
zesses automatisieren. 

Die oben angegebenen möglichen Unterstützungsleistungen sind dem po- 
tenziellen Anwender im Rahmen der Ausgestaltung der IKS transparent zu 
machen. Dies betrifft zum einen die eigentlichen Funktionalitäten (z.B. wel- 
che Verfahren verwendet werden oder wie schnell Anfragen beantwortet wer- 
den sollen), zum anderen aber auch die Gestaltung der IKS (Benutzeroberflä- 
che u. A.), um dadurch die Akzeptanz und Nutzung der Systeme zu erhöhen. 
Die Umsetzung dieser Anforderungen (durch die Wirtschaftsinformatik) muss 

Zu verschiedenen Konzepten und Anwendungen des Data Mining vgl. u. a. Fay- 

yad und Uthurusamy (1996). 
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vom IM innerhalb des Managements der Informations- und Kommunikations- 
systeme geplant und gesteuert werden. 



3.4 Management der Informations- und 
Kommunikationssysteme 

Die Ebene der Informations- und Kommunikationssysteme beinhaltet alle 
Aufgaben, die mit der im Unternehmen verwendeten oder zukünftig einzu- 
setzenden Software im Zusammenhang stehen. Hierzu gehören demnach u. a. 
die Entwicklung einer Informationssystemstrategie (aufbauend auf einer Ana- 
lyse der bisher eingesetzten Systeme), daran anschließend die Planung und 
Steuerung der Beschaffung bzw. Entwicklung dieser Software (vgl. Kapitel 6) 
sowie alle Aufgaben der Nutzung der IKS. 

Ein Informations- und Kommunikationssystem durchläuft idealerweise 
den in Abbildung 3.6 dargestellten Systemlebenszyklus', vgl. u. a. Seibt (1993). 
Der Systemeinsatz beinhaltet dabei einen sich mehrfach wiederholenden 
Kreislauf aus Forderungen nach Veränderungen des Systems (z. B. wenn Feh- 
ler auftreten, wenn die Anwender neue Funktionen im IKS abgebildet haben 
möchten oder wenn durch eine Änderung anderer Systeme Anpassungen nötig 
werden), deren Umsetzung sowie ein begleitendes IV-Controlling. Das Ende 
des Systemlebenszyklus bildet die Systemstilllegung. 




Abbildung 3.6. Phasen des Systemlebenszyklus; nach Seibt (1993), S. 21 



In der Praxis kommt es jedoch nicht selten vor, dass keine vollständige Ablösung 
eines Systems durch ein anderes erfolgt, d. h. dass keine wirkliche Stilllegung 
vorgenommen wird. So wird oftmals zwar ein neues IKS eingeführt, das alte 
jedoch (zur Sicherheit) nicht gelöscht. 
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Der Entwicklung und dem Einsatz von IKS vorgelagert ist die Bestim- 
mung einer Strategie hinsichtlich der im Unternehmen einzusetzenden Soft- 
waretechnologie. Hierzu gehören z. B. Entscheidungen über den Einsatz von 
betriebswirtschaftlicher Standardsoftware für die integrierte Informationsver- 
arbeitung (Enterprise Resource Flanning; vgl. Kapitel 7) oder den Aufbau 
eines Data Warehouse; vgl. Abschnitt 5.5. Die Strategieentwicklung beinhal- 
tet demzufolge grundsätzliche Entscheidungen über den langfristigen Einsatz 
einer Softwaretechnologie. 

Aufgrund der Verflechtungen zwischen Softwaresystemen und der ihnen 
zu Grunde liegenden IT-Infrastruktur (im Sinne von Hardware, Netzwerken 
und Systemsoftware; vgl. Abschnitt 3.5) beeinflussen sich die Entwicklung 
einer IKS-Strategie und einer Strategie für die IT-Infrastruktur gegenseitig. 
Die folgenden Ausführungen beziehen sich daher auf die strategische Planung 
sowohl von IKS als auch der IT-Infrastruktur. 

Grundlage für eine Strategieentwicklung ist die Ermittlung der strategi- 
schen Bedeutung der IT für das Unternehmen. Für einen Handwerksbetrieb 
werden Informationen (und somit auch die IT) in der Regel eine im Vergleich 
zu Unternehmen des Electronic Gommerce (vgl. Abschnitt 7.6) geringere Be- 
deutung für den Unternehmenserfolg besitzen. Die wesentliche Zielsetzung 
der Strategieentwicklung besteht somit darin, die IT gemäß ihrer (zukünfti- 
gen) Bedeutung für das Unternehmen auszurichten, d. h. möglichst langfristig 
Technologien auszuwählen und - verbunden mit einer entsprechenden Or- 
ganisationsentwicklung - umzusetzen, die den künftigen Anforderungen des 
Unternehmens an seine Informationsversorgung am ehesten entsprechen. 

Diese Anforderungen ergeben sich aus der Unternehmensstrategie, die 
sich u. a. in einer Marktstrategie, sowie einer Investitions- und Personalpla- 
nung konkretisiert. Ausgehend von abgeleiteten IT-Bedarfen kann durch Soll- 
Ist- Analysen eruiert werden, inwiefern eine grundsätzliche Veränderung der 
IT-Landschaft im Unternehmen notwendig ist. Die Entscheidung über den 
Einsatz einer Technologie geschieht dann auf der Grundlage von Kosten- 
Nutzen- Analysen sowie verschiedenen Portfoliotechniken im Rahmen des IT- 
Gontrolling; vgl. hierzu die Ausführungen am Ende des Abschnitts 3.2. 

Eine wesentliche Problematik der Strategieentwicklung besteht in der Tat- 
sache, dass die IT einem raschen Wandel unterworfen ist. Demzufolge kann 
aufgrund der Langfristigkeit der Entscheidung für eine IT-Strategie nicht je- 
de technologische Weiterentwicklung in das Unternehmen einfließen. Gleich- 
zeitig kann jedoch zum Zeitpunkt einer derartigen Entscheidung kaum ab- 
geschätzt werden, ob nicht in naher Zukunft eine für den vorgesehenen Ein- 
satzzweck besser geeignete Technologie verfügbar sein wird. Darüber hinaus 
müssen bei diesen Entscheidungen auch die bereits vorhandenen IKS und 
IT-Infrastrukturen berücksichtigt werden, um eine integrierte Informations- 
verarbeitung zu gewährleisten. 

Ausgehend von der entwickelten IKS-Strategie hat das IM die Aufgabe, 
die Beschaffung bzw. Entwicklung der benötigten Softwaresysteme zu planen. 
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zu steuern und zu kontrollieren. Im Folgenden werden einige dieser Software- 
systeme vorgestellt, die insbesondere der Unterstützung des Informationsein- 
satzes dienen. 

Zur Bereitstellung (und teilweise auch Nutzung) von Informationen und 
Wissen sind Management-Support-Systeme weit verbreitet, worunter unter- 
schiedlichste Systeme zusammengefasst werden. So können verschiedene Ent- 
scheidungsprozesse - von einfachen operativen Entscheidungen bis hin zu 
nicht standardisierbaren Einzelentscheidungen - unterstützt werden. Auch 
der Grad der Unterstützung variiert zwischen den Systemen, d. h. die An- 
wendungsmöglichkeiten reichen von einer einfachen Bereitstellung von Infor- 
mationen (z. B. in Form von Reports^^), über deren Verarbeitung bis hin zu 
einer (Teil-)Automatisierung von Entscheidungsprozessen, wofür geeignete 
Modelle und Methoden notwendig sind. 

Uber eine einfache Informationsbereitstellung hinaus gehen Entschei- 
dungsunterstützungssysteme (englisch: Decision Support Systems). Hierun- 
ter versteht man interaktive, computergestützte Systeme zur Unterstützung 
von Planungsaufgaben und den damit verbundenen Entscheidungen. Hierfür 
müssen diese Systeme Modelle und Methoden für den gesamten Entschei- 
dungsprozess enthalten sowie eine hohe Flexibilität besitzen, um eine An- 
passung bzw. eine flexible Kombination dieser Modelle und Methoden hin- 
sichtlich der zu unterstützenden Entscheidung zu ermöglichen. Wesentliche 
Bestandteile derartiger Systeme sind neben einer Modell- und Methoden- 
komponente eine Datenkomponente (z. B. eine Datenbank; vgl. Kapitel 5) 
und eine Dialogkomponente, mittels derer der Anwender Daten und Modelle 
miteinander verknüpfen kann. 

Eine automatisierte Generierung von Lösungen (und dadurch die Un- 
terstützung der Wissensnutzung und -bewahrung) soll durch so genannte 
Wissensbasierte Systeme (Expertensysteme) ermöglicht werden. Diese Syste- 
me haben das Ziel, das Wissen menschlicher Experten zu erfassen, zu formali- 
sieren und die Problemlösungsfähigkeit von Menschen nachzuahmen. Wesent- 
liches Merkmal ist die Trennung des (anwendungsbezogenen) Wissens von 
den (anwendungsunabhängigen) Mechanismen zum Umgang mit der Wis- 
sensbasis. Wissensbasierte Systeme bestehen somit aus folgenden Kompo- 
nenten: 

• Wissensbasis (unterteilt in fallspezifisches Wissen, bereichsbezogenes Ex- 
pertenwissen sowie Zwischen- und Endergebnisse von Problemlösungen), 

• Inferenzkomponente (für das Ableiten von Schlüssen und die Interpretati- 
on), 

• Interviewkomponente (Schnittstelle zum Benutzer), 

• Erklärungskomponente (zum Nachvollziehen des Inferenzprozesses), 

Dabei lassen sich einfache, z. B. wöchentlich generierte Berichte sowie Ausnah- 
mereports unterscheiden. Ausnahmereports werden nur dann generiert und Ent- 
scheidungsträgern bereit gestellt, wenn sich signifikante Abweichungen gegenüber 
vorgegebenen Größen (Soll-Ist- Vergleich) einstellen. 
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• Wissenserwerbs- bzw. Wissensakquisitionskomponente (Schnittstelle zum 
Experten). 

Um eine wirkliche Unterstützung von Entscheidungsprozessen durch die 
mittels derartiger Systeme bereitgestellten Informationen, Entscheidungs- 
modelle oder das dort abgelegte Wissen zu erreichen, müssen diese IKS 
tatsächlich genutzt werden. Die Gefahr einer ineffizienten Nutzung oder sogar 
Nichtakzeptanz solcher Systeme kann durch ein geeignetes Management der 
IKS verringert werden. Besondere Bedeutung hat in diesem Zusammenhang 
die Konzeption und Entwicklung bzw. die Beschaffung von IKS. Neben den 
geforderten Funktionalitäten muss hier auch auf eine geeignete Gestaltung 
des Systems geachtet werden. Daraus ergibt sich, dass das IM Anforderungen 
an die Wirtschaftsinformatik hinsichtlich der Ausgestaltung der IKS stellt, die 
insbesondere im Rahmen der Softwareentwicklung zu berücksichtigen sind. 

Neben dem Management von IKS stellt das Datenmanagement einen wei- 
teren wichtigen Aufgabenbereich innerhalb der mittleren Ebene des Ebe- 
nenmodells dar. Dieses beinhaltet idealerweise den Entwurf und die Umset- 
zung eines unternehmensweiten Datenhaltungskonzeptes. Hierzu zählt auch 
die Konzeption von Datenbanken, weshalb das Datenmanagement in diesem 
Buch in Abschnitt 5.6 innerhalb des Kapitels zu Datenbanken behandelt wird. 



3.5 Management der Informations- und 
Kommunikationsinfrastruktur 

Ausgehend von der Informationsbedarfsanalyse und den einzusetzenden IKS 
ergeben sich diverse Anforderungen an die diesen Systemen zu Grunde liegen- 
de Infrastruktur. Die Informationstechnologie-Infrastruktur beinhaltet Hard- 
ware (Rechner und Netze), Betriebssystemsoftware, Kommunikationsmittel 
und Werkzeuge, die für die Anwendung von Software benötigt werden, sowie 
Komponenten zu ihrer Integration in ein Gesamtsystem. Die IT-Infrastruktur 
dient somit als Basis für den Einsatz von Anwendungssoftware und sollte 
demzufolge unternehmensweit geplant, gesteuert und kontrolliert werden (um 
sie z. B. als Grundlage für verschiedene Geschäftsbereiche zu nutzen). 

Auch auf dieser Ebene finden sich sowohl strategische Aufgaben, wie die 
Strategieentwicklung für die Infrastruktur (vgl. hierzu Abschnitt 3.4) sowie 
die Vorsorge vor Schadensfällen mit Hilfe des Sicherheits- und Katastrophen- 
managements, als auch taktische oder operative Aufgaben. Dazu zählen u. a. 
die Beschaffung der infrastrukturellen Komponenten sowie ihr Betrieb (ein- 
schließlich der Benutzerbetreuung und der Wartung und Pflege der eingesetz- 
ten Systeme). 

In Abhängigkeit vom jeweiligen Betrachtungsgegenstand lassen sich das 
Netzwerkmanagement sowie das Rechner- und Installationsmanagement un- 
terscheiden. Zu Letzterem gehören auch die Planung, Installation und Ver- 
waltung der Systemsoftware. Beide Aufgabenfelder beinhalten die Fehlerdia- 
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gnose und -behebung innerhalb ihres Zuständigkeitsbereiches. Ziel ist jeweils 
die Gewährleistung einer möglichst uneingeschränkten Verfügbarkeit der IT, 
wobei die Gesichtspunkte Effizienz und Flexibilität zu berücksichtigen sind. 

Von großer Bedeutung für den reibungslosen Einsatz der verschiedenen 
IT-Komponenten ist die Abwendung von potenziellen Schäden, wobei derar- 
tige Schäden nicht nur die IT-Infrastruktur betreffen (sondern z.B. auch den 
Verlust von Daten). Ausgehend von den potenziellen Schäden lassen sich 
die beiden Bereiche Sicherheitsmanagement und Katastrophenmanagement 
unterscheiden. 

Das Sicherheitsmanagement beschäftigt sich mit dem Abwenden oder 
Vermindern realer Schäden, insbesondere der Gewährleistung von Datensi- 
cherheit und Datenschutz. Datensicherheit bedeutet, den Verlust oder die 
Verfälschung von Daten (Informationen) zu verhindern. Dies kann insbeson- 
dere über die Verwaltung der Daten über Datenbankmanagementsysteme 
(vgl. Kapitel 5), den Zugriff auf die Daten unter Beachtung von Integritätsbe- 
dingungen und eine geplante Datenredundanz (Spiegelung, Backup usw.) in- 
klusive entsprechender organisatorischer Maßnahmen erreicht werden. Daten- 
schutz verfolgt demgegenüber die Zielsetzung, Informationen über persönli- 
che Lebenssachverhalte in gewissen Grenzen zu schützen; vgl. Abschnitt A.6. 
Basierend auf dem „Recht auf informationeile Selbstbestimmung“ existieren 
umfangreiche Rechtsvorschriften, die Bedingungen bei Erhebung, Verarbei- 
tung und Nutzung personenbezogener Daten festlegen, die von Unternehmen 
zu erfüllen sind. Hieraus ergeben sich verschiedene organisatorische und tech- 
nische Maßnahmen. 

Potenzielle Fälle im Bereich des Sicherheitsmanagements entstehen so- 
wohl durch Bedrohungen von außen als auch von innen, wobei Letztere oft- 
mals nicht absichtlich hervorgerufen werden, sondern durch versehentliche 
Fehlbedienungen oder auch falsche Einstellungen im System (z. B. Benutzer- 
rechte) bedingt sind. Dabei kann ein Verlust der (aktuellen) Funktionalität 
von Informationssystemen eintreten (beispielsweise infolge des Löschens von 
Anwendungssystemdateien). Neben der schon erwähnten Nachlässigkeit im 
Umgang mit den Datenbeständen können technische Probleme sowie Viren 
u. A., aber auch deliktische Handlungen, wie Datendiebstahl, Sabotage usw., 
Ursache von Schadensfällen sein. 

Im Gegensatz zum Sicherheitsmanagement beschäftigt sich das Katastro- 
phenmanagement mit der Planung von Schadensfällen, deren Eintrittswahr- 
scheinlichkeit extrem niedrig ist, die jedoch sehr negative Folgen beziehungs- 
weise einen potenziell sehr hohen Schaden zur Folge haben. Derartige Ka- 
tastrophen können u. a. ein Ausfall des Rechenzentrums (z.B. durch Brand) 
oder der (temporäre) Ausfall eines wichtigen Servers infolge einer Zerstörung 
der Netzwerkanbindung durch Baggerarbeiten sein. In jedem Fall stellt sich 
die Frage, wie eine Katastrophe behandelt werden kann. Ziel des Katastro- 

Nichtsdestotrotz sind auch im Rahmen der Systementwicklung und des System- 
betriebes Sicherheitsaspekte zu berücksichtigen. 
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phenmanagements ist daher eine systematische Notfallplanung. Diese besteht 
zum einen aus der Vorsorgeplanung, d.h. der Ausarbeitung und Durchset- 
zung von Vorsorgemaßnahmen gegen den Eintritt eines Katastrophenfalles, 
und zum anderen aus der Einsatz- und Wiederanlaufplanung von Maßnah- 
men bei und nach Eintritt des Katastrophenfalles. Hierfür sind verschiedene 
Szenarien für Katastrophen zu berücksichtigen und entsprechende Katastro- 
phenpläne (betreffend Leitfaden, Einsatzplan, Krisenstab usw.) zu bilden. 
Eine Möglichkeit zur Schadensreduzierung besteht dabei in der Fremdvorsor- 
ge, z. B. durch die Sicherstellung eines Ausweichens auf andere Rechenzentren 
im Notfall oder den Abschluss von Versicherungen zur Verminderung des fi- 
nanziellen Risikos. 

Aus dem Ziel des Managements der IT-Infrastruktur, eine möglichst weit- 
gehende Unterstützung der Informationssysteme bzw. des Informationsein- 
satzes zu gewährleisten, ergibt sich der Wunsch, dass jeder Anwender die 
von ihm genutzten, im Unternehmen verteilt vorliegenden Ressourcen von 
jedem Arbeitsplatz in gleichem Umfang nutzen kann. Dies zu ermöglichen 
ist das Ziel des Architekturmanagements, dessen Aufgabe im integrierten 
Management der unternehmensweiten Informations- und Kommunikations- 
system-Installation besteht. Dabei muss jedoch berücksichtigt werden, dass 
Veränderungen der IT-Infrastruktur neben technischen Auswirkungen auch 
organisatorische und juristische Auswirkungen (z.B. hinsichtlich des Daten- 
schutzes) haben können. Hauptaufgabe des Architekturmanagements ist je- 
doch das technische Management verteilter heterogener Informations- und 
Kommunikationssysteme, das einen starken Bezug zu den anderen Bereichen 
des IT-Infrastruktur-Managements besitzt. 



3.6 Organisationsentwicklung 

Eine Aufgabe des Informationsmanagements besteht im Erkennen (und der 
Umsetzung) von Potenzialen der IT für die Unternehmensführung. Damit 
wird eine gegenseitige Beeinflussung von Unternehmensstrategie (an der die 
Gestaltung der innerbetrieblichen IT prinzipiell auszurichten ist) und den 
Entwicklungen im Bereich der IT (die wiederum neue Geschäftsfelder, Kun- 
den bzw. Partner erreichbar macht) impliziert. In diesem abschließenden Ab- 
schnitt wenden wir uns deshalb Möglichkeiten der IT-induzierten Organisa- 
tionsentwicklung zu. 

Ausgangspunkt unserer Betrachtungen bilden wiederum Transaktionskos- 
ten. Die Höhe der Transaktionskosten hängt nicht nur von der Art und 
Häufigkeit der zu erbringenden Leistung ab, sondern im Wesentlichen von 
der Organisation eines Unternehmens an sich sowie der Gestaltung seiner 
Beziehungen zu Lieferanten, Kunden und sonstigen Partnern. 

So kann der Einsatz geeigneter Kommunikationsmittel zwischen einem 
Unternehmen und seinen Lieferanten die Transaktionskosten für den zwi- 
schenbetrieblichen Informationsaustausch reduzieren. Hierfür können jedoch 
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organisatorische Veränderungen in den beteiligten Unternehmen notwendig 
sein. 

Organisationsinterne Veränderungen umfassen nicht nur eine 
(Teil-)Automatisierung (im Sinne der Rationalisierung) von bestehen- 
den Abläufen, sondern vielmehr eine prinzipielle Veränderung der Aufteilung 
der Arbeit und entsprechender Verantwortungsbereiche. Neben einer geeig- 
neten informationstechnischen Unterstützung der Abläufe im Unternehmen 
kann die Höhe der Transaktionskosten somit auch durch die Koordina- 
tionsform (der Informationsbeziehungen) eines Unternehmens beeinflusst 
werden. 

In Abhängigkeit von dem mit einem Aufgabenbereich verbundenen Hand- 
lungsspielraum eines Entscheidungsträgers^'^ können unterschiedliche Koor- 
dinationsformen (d. h. organisatorische Rahmenbedingungen hinsichtlich der 
Beziehungen handelnder Personen in einem Unternehmen sowie der damit 
einhergehenden Entscheidungskompetenzen und Informationsbeziehungen) 
sinnvoll sein. In Abbildung 3.7 wird dieser Zusammenhang verdeutlicht. Bei 
einem großen Handlungsspielraum ist in der Regel eine hierarchische Or- 
ganisationsform zu präferieren. Je geringer der Handlungsspielraum bei ei- 
ner Entscheidung ist, desto eher können entsprechende Leistungen über den 
Markt bezogen werden. So sollte die Entwicklung der IT-Strategie, für die ein 
hoher Entscheidungsspielraum zu konstatieren ist, unternehmensintern erfol- 
gen, sofern diese für den langfristigen Erfolg eines Unternehmens eine hohe 
Bedeutung besitzt. Demgegenüber können z. B. Aufgaben des Netzwerkma- 
nagements aufgrund ihrer geringeren Spezifität an andere Unternehmen ab- 
gegeben werden. 




Abbildung 3.7. Einfluss der Informationstechnik und Spezifität auf Transaktions- 
kosten und Wahl der Koordinationsform; vgl. Picot et al. (1996) 



In diesem Zusammenhang beschreibt die so genannte Spezifität einer Aufgabe 
den Aufwand, den ein Auftraggeber zu erbringen hat, um festzustellen, ob und 
inwieweit der Auftragnehmer die Aufgabe im Sinne des Auftraggebers erfüllt 
hat. 
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Leistungen mit geringer Spezifität über den Markt zu beziehen, wird als 
Outsourcing bezeichnet. Hierunter versteht man die Auslagerung insbeson- 
dere von Aufgaben des Informationsmanagements an externe Partner; vgl. 
Szyperski et al. (1993). Insbesondere bieten sich verschiedene administrati- 
ve und operative Aufgaben des IT-Managements für ein Outsourcing an. So 
kann die auf Basis strategischer Entscheidungen veranlasste Softwareentwick- 
lung im Allgemeinen (auch bei Individualsoftware; vgl. Abschnitt 2.4.4) von 
externen Dienstleistungsunternehmen übernommen werden. 

Entsprechende Koordinationsformen werden durch die derzeitige Entwick- 
lung zum Käufermarkt mit höherer Marktunsicherheit und einer höheren 
Produktkomplexität gefördert. Diese beiden Faktoren stellen wichtige Ein- 
fiussgrößen für die Auswahl einer Koordinationsform dar; vgl. Abbildung 3.8. 
Unternehmen sind in diesem Zusammenhang oftmals bestrebt, sich zum einen 
auf Kernkompetenzen zu konzentrieren und zum anderen strategische Part- 
nerschaften einzugehen. Entsprechende Koordinationsformen fußen maßgeb- 
lich auf der Nutzung bzw. Entwicklung geeigneter IT-Infrastruktur. Insbe- 
sondere beim Übergang zu neuen Unternehmensformen, d. h. Veränderungen 
hinsichtlich der Koordinationsform, lassen sich demzufolge durch intelligen- 
ten Einsatz von IT Transaktionskosten reduzieren. Mögliche Koordinations- 
formen sind organisationsintern die Modularisierung; unternehmensübergrei- 
fend stellen die Bildung strategischer Netzwerke oder virtueller Unternehmen 
wesentliche Ausprägungen IT-induzierter Organisationsentwicklung dar. 




Abbildung 3.8. Wandel der Marktsituation und Reorganisationsbedarf; nach Pri- 
billa et al. (1996) 
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Unter Modularisierung versteht man hierbei die Umstrukturierung eines 
Unternehmens in relativ kleine, überschaubare Einheiten (Module), die ei- 
ne dezentrale Entscheidungskompetenz und Ergebnisverantwortung besitzen. 
Grundlage der Aufteilung in Module sind oftmals integrierte, kundenorien- 
tierte Prozesse; Ziele sind insbesondere die Reduktion der Anzahl der am 
Leistungsprozess beteiligten Organisationseinheiten und der damit verbun- 
denen Schnittstellen sowie die Verbesserung der Kundennähe. Auch wenn 
sich der Koordinationsaufwand bezüglich eines jeden Prozesses verringert, so 
ist dennoch zu konstatieren, dass der insgesamt anfallende Koordinations- 
aufwand im Vergleich zu traditionellen Unternehmensformen höher ausfallen 
kann. Dieser Aufwand lässt sich jedoch durch geeignete IT-Unterstützung 
kompensieren. 

Gründe für die Bildung strategischer Netzwerke können z.B. die Be- 
schränkung auf Kernkompetenzen in Unternehmen sein, womit andere Un- 
ternehmen mit an die eigenen Kernkompetenzen anschließenden Produkten 
bzw. Dienstleistungen als Partner in Frage kommen (z.B. bei Kooperationen 
zwischen einem Mobilfunknetzbetreiber und einem Hersteller von Mobilfunk- 
geräten). Virtuelle Unternehmen (vgl. Abschnitt 1.2) zeichnen sich dadurch 
aus, dass verschiedene Unternehmen in häufig wechselnden Verbünden für 
begrenzte Zeiträume (z.B. die Dauer eines Projektes) kooperieren, jedoch 
keine festen organisatorischen Verflechtungen zwischen ihnen bestehen. Ziele 
sind hierbei die Erhöhung der Flexibilität und die Verringerung von Transak- 
tionskosten, da nur die am jeweiligen Projekt beteiligten Unternehmen bzw. 
Personen untereinander Informationen austauschen müssen. 

Diese neuen Koordinationsformen sind jedoch ohne eine Unterstützung 
durch entsprechende Informationstechnik und Informationssysteme undenk- 
bar. Insbesondere virtuelle Unternehmen hängen in hohem Maße von der IT 
und den verwendeten IKS ab, da eine flexible Zusammenarbeit zwischen ver- 
schiedenen räumlich und organisatorisch getrennten Unternehmen erreicht 
werden soll. Das Informationsmanagement hat somit nicht nur die Aufgabe, 
geeignete Koordinationsformen aufzuzeigen, sondern auch die Aufgabe, die 
hierfür benötigte Infrastruktur zu bestimmen und zur Verfügung zu stellen. 



3.7 Kontrollfragen 

1. Erläutern Sie an einem selbst gewählten Beispiel die Begriffe „Daten“, 
„Information“ und „Wissen“! Grenzen Sie diese Begriffe voneinander ab! 

2. Grenzen Sie Informationsmanagement und Wirtschaftsinformatik defini- 
torisch voneinander ab! Erläutern Sie anhand Ihrer Definitionsansätze, 
ob diese beiden Gebiete eine eigenständige Daseinsberechtigung besitzen! 

3. Nennen und erklären Sie (kurz) wesentliche Aufgaben des Informati- 
onsmanagements! Ordnen Sie diese den Ebenen des Ebenenmodells von 
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Wollnik (vgl. Abbildung 3.2 auf S. 70) zu! 

4. Was stellen Sie sich unter einem persönlichen Informationsmanagement 
vor? 
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Unter einem Modell versteht man eine im Hinblick auf einen Zweck ver- 
einfachte Abbildung eines Realitätsausschnittes oder eines abstrakten Ge- 
genstands als ein Artefakt^, wobei Modelle entsprechend des Zweckbezuges 
gewisse Ähnlichkeiten zum abgebildeten Gegenstandsbereich (Objektsystem) 
besitzen - etwa ein Homomorphismus hinsichtlich Struktur, Funktion oder 
Verhalten. Modellierung im Sinne der Entwicklung von Modellen erfolgt, um 
Phänomene der Wirklichkeit zu beschreiben, zu erklären und zu gestalten. 
Um für den jeweiligen Zweck unwesentliche Komplexität zu reduzieren, ist 
im Rahmen der Modellierung eine Abstraktion notwendig, wobei Teile der 
Realität ausgeblendet oder durch eine einfachere Darstellung ersetzt wer- 
den können. Dabei erfolgt häufig eine Loslösung vom Konkreten im Sinne 
einer verallgemeinernden Typisierung relevanter Sachverhalte (z.B. die Ein- 
ordnung aller Kunden eines Unternehmens gemäß eines verallgemeinernden 
Schemas) . 

Typische Modellierungszwecke sind die Entwicklung von Anwendungssys- 
temen, die Dokumentation, Analyse und Optimierung von Geschäftsprozes- 
sen, die Unterstützung der Konfiguration und Einführung von Standardan- 
wendungssoftware, das Wissensmanagement, die Simulation von Fertigungs- 
anlagen oder die Einführung einer Prozesskostenrechnung. Aufgrund der Viel- 
falt der Anwendungsbereiche ergeben sich unterschiedliche Anforderungen, so 
dass verschiedenste Modellierungsmethoden entwickelt wurden, die die Form 
der Modellierung regeln. 

Im Rahmen der Unternehmensmodellierung stellen Unternehmen bzw. 
entsprechende betriebliche Gegebenheiten den betrachteten Wirklichkeitsaus- 
schnitt dar. Die Modellierung entsprechender Strukturen und Abläufe ist die 
Grundlage für eine Beurteilung der Potenziale einer informationstechnischen 
Unterstützung der Abwicklung von Geschäftsprozessen. Auf dieser Basis kann 
die Gestaltung von Anwendungssystemen über die Entwicklung entsprechen- 
der Entwurfsmodelle unterstützt werden. In diesem Zusammenhang werden 
Phänomene eines Unternehmens primär als Nachbild modelliert (im Sinne 
eines Ist-Modells eines realen Objektsystems), während der Entwurf von An- 

^ Der Begriff Artefakt (vom Lateinischen: „arte“ mit Kunst; „factum“ das Gemach- 
te) bezeichnet ein durch menschliche oder technische Einwirkung entstandenes 
Produkt oder Phänomen. 
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Wendungssystemen primär einen konstruktiven Vorbildcharakter besitzt (im 
Sinne eines Soll-Modells). Andererseits kann sich die Vor- bzw. Nachbild- Rolle 
auch umgekehrt darstellen - etwa wenn ein bestehendes Anwendungssystem 
über Modelle nachgebildet wird, während Geschäftsprozessmodelle im Sinne 
von Referenzmodellen als Vorbild für veränderte bzw. neue Abläufe dienen 
können; vgl. die Abschnitte 3.6 und 4.1.3. In diesem Zusammenhang können 
Modelle dahingehend klassifiziert werden, inwieweit ein beschreibender, er- 
klärender oder gestaltender Charakter vorliegt. Aufbauend auf einer Be- 
schreibung bilden erklärende Modellaspekte insbesondere Ursache- Wirkungs- 
Beziehungen (Kausalitäten) ab. Idealtypisch ergibt sich eine Abfolge von Be- 
schreibung, Erklärung sowie eine anschließende (Neu-) Gestaltung von Syste- 
men. 

Weitere allgemeine Klassifikationsmerkmale für Modellierungsmethoden 
bzw. entsprechende Modelle sind die Realitätsnähe bzw. der Grad der Ver- 
einfachung (Abstraktionsgrad) sowie die Formalisierung (der Grad der Fest- 
legung von Syntax und Semantik der Modellierungskonstrukte) und die ent- 
sprechende Darstellungstechnik (z. B. natürlichsprachig, graphisch, mathe- 
matisch). In Abhängigkeit von der Abbildung von Unsicherheiten kann man 
in deterministische und stochastische Modelle unterscheiden. 

Des Weiteren können Modellierungsmethoden dahingehend klassifiziert 
werden, ob statische oder dynamische Zusammenhänge abgebildet werden 
und ob diese Abbildung statisch oder dynamisch erfolgt. Damit ergeben sich 
folgende Möglichkeiten; vgl. Voß und Gutenschwager (2001): 

1. (statische) Abbildung von statischen Zusammenhängen, 

2. statische Abbildung von Prozessen, 

3. dynamische Abbildung von Prozessen. 

Der erste Ansatz wird z. B. für die Abbildung von Organisationsstruk- 
turen, Funktionshierarchien und Datenbeständen genutzt, wofür u. a. die 
Entity-Relationship-Modellierung genutzt werden kann; vgl. Abschnitt 4.2.1. 
Die statische Abbildung von Prozessen wird z.B. bei der Darstellung von 
Arbeitsablaufplänen eingesetzt, wobei die einzelnen Schritte des Prozesses 
beschrieben werden, nicht jedoch die im Zeitverlauf auftretenden Verände- 
rungen des abgebildeten Systems. Will man diese Veränderungen ebenfalls 
nachvollziehen, so ist eine dynamische Modellierung zu wählen, z. B. die Si- 
mulation; vgl. Abschnitt 4.6. So kann bei der Simulation eines Lagers zu 
jedem Zeitpunkt der Lagerbestand nachvollzogen werden, der sich durch die 
Ein- und Ausgänge von Gütern im Zeit verlauf ändert. 

Mit Blick auf den verfolgten Modellierungszweck beschränkt man sich bei 
der Modellierung häufig auf die Abbildung bestimmter Aspekte (so genann- 
ter Sichten). Bei der Unternehmensmodellierung bedeutet dies insbesondere 
eine Fokussierung auf statische, strukturelle Aspekte (z. B. Aufbauorganisa- 
tion, relevante Daten) oder eher dynamische Aspekte (z.B. Ablauforganisa- 
tion, Datenflüsse); vgl. Abschnitt 4.1.1. Hiervon unabhängig spricht man in 
Abhängigkeit von der Nähe zur Informationstechnik auch von verschiedenen 
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(Betrachtungs-)Ebenen der Modellierung. Die zweckorientierte Verwendung 
verschiedener Sichten und Ebenen entspricht dem Modellierungsprinzip der 
Abstraktion; erst hierdurch wird es möglich, Komplexität zu reduzieren und 
handhabbare Modelle zu entwickeln. 

Systematische Formen der Modellierung erfolgen auf der Basis so genann- 
ter Metamodelle, in denen die Syntax und Semantik von Modellierungskon- 
strukten (statisch-strukturelles Metamodell) sowie gegebenenfalls zugeordne- 
te Vorgehensweisen bei der Modellierung (prozessuales Metamodell) festge- 
legt sind. Die Interpretation von Modellen basiert damit immer auf entspre- 
chenden - explizit formulierten oder implizit angenommenen - Metamodellen. 
Ein statisch-strukturelles Metamodell definiert die zulässigen Modellierungs- 
konstrukte (z.B. Objekttypen), die anwendungsabhängig in Modellen ver- 
wendet werden können (z.B. Objekttyp Kunde), wovon wiederum konkrete 
Ausprägungen existieren (z. B. „Kunde Meier“ als Exemplar des Objekttyps 
Kunde). Demgemäß ergeben sich verschiedene Ahstraktionsstufen, die über 
eine Typisierung miteinander verknüpft sind (d. h., Modellelemente auf einer 
Abstraktionsstufe stellen jeweils Ausprägungen von Modellelementen auf der 
nächsthöheren Abstraktionsstufe dar). 

Die in den folgenden Abschnitten beschriebenen Modellierungsmethoden 
werden insbesondere im Rahmen der Entwicklung von Anwendungssystemen 
eingesetzt. Da Anwendungssysteme aus Software bestehen, zielt die Model- 
lierung im Rahmen der Anwendungssystementwicklung letztendlich auf for- 
male, ausführbare Modelle ab (etwa die Abbildung von einfachen Abläufen 
in Form von Workflows, die direkt in Workflow-Management-Systemen ver- 
wendet werden können). In diesem Zusammenhang kann sich die Modellie- 
rung damit nicht in der Erstellung konzeptioneller Modelle erschöpfen, auf 
deren Basis die eigentliche Systementwicklung losgelöst erfolgt. Stattdessen 
sollten Entwurfsmodelle idealerweise automatisiert in ausführbare Implemen- 
tierungsmodelle umgesetzt werden können (z. B. die Übertragung eines Da- 
tenmodells in eine konkrete Datenbank). Voraussetzung hierfür ist einerseits 
die Verwendung formaler und kompatibler Modellierungs- und Implemen- 
tierungstechniken auf verschiedenen Ebenen. Andererseits ist eine effizien- 
te Unterstützung entsprechender Entwicklungsprozesse durch zweckmäßige 
Softwarewerkzeuge erforderlich. Vor diesem Hintergrund kann sich ein Ent- 
wurfsmodell im Idealfall direkt in entsprechenden IT-Systemen widerspiegeln; 
vgl. z.B. Taylor (1995). 

Im Zusammenhang mit der Entwicklung von Anwendungssystemen als 
Teil von Informations- und Kommunikationssystemen ist die Unterstützung 
betrieblicher Planungs- und Entscheidungsprozesse ein weiterer zentraler 
Zweckbereich der Modellierung. Dabei dienen Simulationsmodelle der expe- 
rimentellen Analyse verschiedener Konfigurationsalternativen bzw. Szenarien 
für komplexe dynamische Systeme; vgl. Abschnitt 4.6. Sofern ein quantita- 
tiv abbildbares, analytisches Verständnis der Problemstellung vorliegt bzw. 




94 



4. Modellierung 



Über entsprechende Vereinfachungen angenommen wird, können mathemati- 
sche Optimierungsmodelle zum Einsatz kommen; vgl. Abschnitt 4.7. 



4.1 Unternehmensmodellierung 

Die Bedeutung der Unternehmensmodellierung für die Wirtschaftsinforma- 
tik ergibt sich insbesondere im Rahmen der informationstechnischen Un- 
terstützung der Abwicklung von Geschäftsprozessen. Hierfür ist ungeachtet 
der Vielfalt entsprechender Aufgaben eine Modellierung betrieblicher Struk- 
turen und Abläufe unabdingbar. In den folgenden Abschnitten dieses Ka- 
pitels wird insbesondere darauf eingegangen, wie man hierbei systematisch 
zweckorientierte Teilmodelle bilden und nutzen kann und welche Modellie- 
rungsmethoden hierfür auf einer betriebswirtschaftlich-fachlichen Ebene zur 
Verfügung stehen. 

Nicht näher eingegangen wird in diesem Kapitel auf einige der bereits in 
Kapitel 3 betrachteten Themen wie z. B. die Analyse von Informationsbedar- 
fen, das Wissensmanagement und die Organisationsentwicklung. Nichtsdesto- 
trotz ist nochmals zu betonen, dass die simultane Betrachtung der Gestaltung 
von Informationssystemen und entsprechender Unternehmensstrukturen und 
-abläufe erforderlich ist; vgl. Brynjolfsson und Hitt (2000). 

4.1.1 Sichten, Ebenen und Integration 

Bei der Unternehmensmodellierung definieren zweckorientierte Sichten die 
zu modellierenden Aspekte des Unternehmens(ausschnittes). Sichten be- 
stimmen bei der Bildung von Teilmodellen den eingenommenen Blickwin- 
kel (im Sinne einer Ähnlichkeit des semantischen Zusammenhangs zwi- 
schen Elementen des Objektsystems und Modellelementen). Vor dem Hin- 
tergrund der Entwicklung von Informationssystemen bilden die Datensicht, 
die (Aufbau-)Organisationssicht sowie die Funktions- und Prozesssicht (Ver- 
haltenssicht) die grundlegenden Perspektiven einer Modellierung. Im Weite- 
ren werden die Sichten und Ebenen der Unternehmensmodellierung sowie sich 
hieraus ergebende Integrationserfordernisse einführend dargestellt. In den fol- 
genden Abschnitten dieses Kapitels erfolgt eine nähere Betrachtung gemäß 
einer sichtenorientierten Gliederung. 

Aus der Datensicht bilden die im Unternehmen vorhandenen bzw. erzeug- 
ten Daten den zentralen Gegenstand der Unternehmensmodellierung. Es er- 
folgt eine Abbildung von Informationen über statische Sachverhalte.^ Hierbei 

^ Demgemäß kann man auch von einer Informationssicht bzw. von Informationsob- 
jekten sprechen. Wir folgen hier dagegen der üblichen begrifflichen Fokussierung 
auf Daten, wobei in diesem Zusammenhang eine synonyme Verwendung der Be- 
griffe „Daten“ und „Informationen“ gebräuchlich ist. 
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unterscheidet man teilweise vereinfachend in die Beschreibung von längerfris- 
tig gültigen Zuständen und kurzfristigen oder zeitpunktbezogenen Ereignis- 
sen; erstere bezeichnet man auch als Stammdaten (z.B. Adressen von Kun- 
den, Zusammensetzung von Produkten), letztere als Bewegungsdaten (z.B. 
Kundenaufträge, Lagerzugänge). Datenmodelle basieren insbesondere auf ei- 
ner abstrahierenden Klassifikation und Typisierung relevanter Betrachtungs- 
gegenstände über geeignete Datenstrukturen (z. B. werden Kunden durch eine 
achtstellige Kundennummer, einen Namen, eine Adresse usw. beschrieben). 
Da die wesentlichen Datenstrukturen - unabhängig von den eigentlichen Aus- 
prägungen bzw. Inhalten - in einem Unternehmen im Zeitverlauf relativ sta- 
bil sind, können Datenmodelle die Grundlage für eine langfristig tragfähige, 
systematische Verwaltung von Unternehmensdaten in Datenbanksystemen 
bilden. Auf die Datenmodellierung wird in Abschnitt 4.2 näher eingegangen. 

In der Organisationssicht steht die Abbildung statischer Unternehmens- 
strukturen im Mittelpunkt. Dies bezieht sich insbesondere auf aufbauorga- 
nisatorische Aspekte. Beispielsweise kann ein Modell die Gliederung einer 
Abteilung in elementare personelle Organisationseinheiten (Stellen) und die 
Besetzung von Stellen mit Personen, die damit entsprechende Rollen ein- 
nehmen, abbilden. Weiterhin können auch technische Organisationseinheiten 
betrachtet werden (z.B. Fertigungsanlagen oder Rechnersysteme). Die Orga- 
nisationsmodellierung ist hochgradig relevant, da die informationstechnische 
Unterstützung der Abwicklung von Geschäftsprozessen - unabhängig von ei- 
ner nur teilweisen oder einer vollständigen Automatisierung - Organisations- 
einheiten als Aufgabenträger voraussetzt. Auf die Organisationsmodellierung 
wird in Abschnitt 4.3 näher eingegangen. 

In der Funktionssicht bilden Funktionen den primären Betrachtungsge- 
genstand der Modellierung. Funktionen stehen in einem engen Zusammen- 
hang mit aus (Unternehmens-)Zielen abgeleiteten Aufgaben. Beispiele für 
Funktionen sind die Abwicklung eines Kundenauftrags oder die Erstellung 
des Jahresabschlusses. Entsprechende Verrichtungen lassen sich in einem ab- 
strakten Sinne als eine Transformation von Objekten auffassen; dabei kann 
es sich um Material und/oder Informationen handeln. In Funktionsmodel- 
len ist damit primär abzubilden, wie eine solche Transformation definiert ist 
und umgesetzt werden kann. Dabei erfolgt häufig einer Gliederung (Dekom- 
position) von Funktionen in Teilfunktionen. Sofern diese Gliederung gemäß 
des prinzipiellen zeitlichen bzw. sachlogischen Ablaufs erfolgt, spricht man 
auch von einer Phasengliederung. Entsprechende Modelle ermöglichen eine 
Abbildung des dynamischen Ablaufs von Prozessen, weshalb man dann auch 
von einer Prozesssicht bzw. einer prozessorientierten Modellierung spricht. 
In diesem Zusammenhang versteht man unter Geschäftsprozessen betriebs- 
wirtschaftlich relevante Prozesse im Sinne einer zusammengehörigen Abfolge 
von Funktionen bzw. Verrichtungen zum Zweck der Leistungserstellung. Im 
Hinblick auf eine informationstechnisch (teil-)automatisierte Abwicklung von 
Geschäftsprozessabläufen besitzen Prozessmodellierungstechniken eine hohe 




96 



4. Modellierung 



Relevanz. Auf die funktions- und prozessorientierte Modellierung wird in Ab- 
schnitt 4.4 näher eingegangen. 

Unabhängig von der eingenommenen Modellierungssicht können Model- 
le in Abhängigkeit von der Nähe zur Informationstechnik auf verschiedenen 
(Betrachtungs-) Ebenen gebildet werden. Gebräuchlich ist eine grobe Gliede- 
rung in drei Ebenen. Zunächst erfolgt eine Abbildung des Wirklichkeitsaus- 
schnittes auf einer betriebswirtschaftlich-fachlichen Ebene. Ein solches Mo- 
dell (Fachkonzept) stellt häufig eine analytische Aufnahme der Ist-Situation 
bzw. Problemstellung dar; allerdings können auch idealisierte Strukturen 
bzw. Soll-Modelle entwickelt werden. Im Rahmen einer modellbasierten Ent- 
wicklung von Anwendungssystemen bestimmt das Fachkonzept das Prob- 
lem und damit die primären Anforderungen an eine informationstechnische 
Lösung, die über konzeptionelle Entwurfsmodelle strukturiert wird (DV- 
Konzept), wobei soweit möglich noch von implementierungstechnischen De- 
tails abstrahiert wird. Auf dieser Grundlage erfolgt schließlich auf der Im- 
plementierungsebene eine Konkretisierung und Ausgestaltung im Detail (in 
Abhängigkeit von den verwendeten Softwarewerkzeugen sowie der gegebenen 
Informations- und Kommunikationsinfrastruktur) Dementsprechend ergibt 
sich in der Regel vom Fachkonzept zum Implementierungsmodell ein steigen- 
der Formalisierungsgrad sowie eine Verschiebung des Modellcharakters von 
einer Nachbild- zu einer Vorbild- Rolle. 

Die Entwicklung von Teilmodellen bezüglich der diskutierten Sichten und 
Ebenen, aber auch bezüglich verschiedener Gegenstandsbereichsausschnitte 
und Detaillierungs- bzw. Aggregationsstufen, erleichtert die Modellbildung 
über eine entsprechende Komplexitätsreduzierung. Andererseits ergeben sich 
Integrationserfordernisse. Es stellt sich beispielsweise die Aufgabe, Beziehun- 
gen zwischen unterschiedlichen Sichten abzubilden. So erfordert eine ganz- 
heitliche Darstellung von Geschäftsprozessen die Abbildung der in eine Funk- 
tion ein- und ausgehenden Daten sowie der für die Ausführung verantwortli- 
chen Organisationseinheiten (Aufgabenträger). Aus dem Blickwinkel des In- 
formationsmanagements ergibt sich ebenfalls das Erfordernis der Abbildung 
von Zusammenhängen zwischen Daten-, Organisations- und Funktionssicht. 
Beispielsweise sind einerseits die Informationsbedarfe für bestimmte betrieb- 
liche Aufgaben bzw. Funktionen (vgl. Abschnitt 3.3.1) sowie andererseits 
organisatorische Verantwortlichkeiten bezüglich der Datenpflege abzubilden. 
Eine besondere Form der Integration von Funktions- und Datensicht ist bei 
der objektorientierten Modellierung zu konstatieren, bei der von vornher- 
ein in Objekten bzw. Objekttypen (Klassen) Datenstrukturen und hiermit 

® Die Untergliederung hinsichtlich der Nähe zur Informationstechnik findet sich be- 
reits im Ebenenmodell des Informationsmanagements; vgl. Abschnitt 3.2. Auch 
dort werden der oberen Ebene eher betriebswirtschaftlich-fachliche und der un- 
teren Ebene eher technische Aufgaben mit Bezug zur verwendeten Informations- 
und Kommunikationsinfrastruktur zugeordnet. Die mittlere Ebene beschäftigt 
sich dort allerdings bereits mit der Software, wogegen hier noch von der konkre- 
ten Implementierung abstrahiert wird. 
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in direktem Zusammenhang stehende Funktionen gekapselt werden; vgl. Ab- 
schnitt 4.5. 

Neben der Integration verschiedener Sichten ist auch die Integration in- 
nerhalb einer Sicht von Bedeutung. So sind insbesondere Zusammenhänge 
zwischen verschiedenen Detaillierungs- bzw. Aggregationsstufen darzustel- 
len. Bezogen auf die Datenmodellierung sind außerdem beispielsweise Uber- 
deckungen zwischen Modellen, die für bestimmte Funktionen bzw. Funktions- 
bereiche entwickelt wurden, aufzuzeigen. Eine entsprechende Datenintegrati- 
on, die die Voraussetzung für die Nutzung derselben Datenbasis in verschie- 
denen betrieblichen Funktionsbereichen bildet, ist hinsichtlich verschiedener 
Zielsetzungen vorteilhaft: 

• Verbesserung der Datenintegrität (Vollständigkeit und Richtigkeit von Da- 
ten) bzw. Vermeidung von Inkonsistenzen (Widersprüchen) 

• Reduktion von überflüssigen Daten (Redundanzen) 

• Erhöhung der Aktualität von Daten 

• Verbesserung der Datenverfügbarkeit 

Die Explizierung der Zusammenhänge zwischen Teil-Modellen über ei- 
ne Integration verschiedener Sichten, Funktionsbereiche sowie Detaillierungs- 
bzw. Aggregationsstufen ist ein kritischer Aspekt der Modellierung betriebli- 
cher Informationssysteme. Eine vollständige und detaillierte Integration führt 
in der Regel zu einem mächtigen, allerdings auch umfangreichen und kom- 
plizierten Unternehmensgesamtmodell. Die Handhabbarkeit solcher Modelle 
bedingt damit insbesondere softwarewerkzeuggestützte Mechanismen für ei- 
ne Verwendung des Unternehmensmodells gemäß bestimmter Zwecke. Die- 
se Anforderung bezieht sich beispielsweise auf eine Modelldekomposition 
gemäß verschiedener Sichtweisen und Abstraktionsebenen. Generell besteht 
die Problematik, dass die Erstellung und laufende Anpassung umfassender 
Unternehmensmodelle eine aufwändige Aufgabe darstellt. Ein entsprechender 
(Mehr-) Aufwand ist in Unternehmen nur dann zu rechtfertigen, wenn Unter- 
nehmensmodelle nicht als Selbstzweck betrachtet werden, sondern effektiv im 
Rahmen bestimmter Aufgaben wie z.B. der Anwendungssystementwicklung 
und Geschäftsprozessoptimierung eingesetzt werden. 



4.1.2 Architektur integrierter Informationssysteme 

Die von Scheer entwickelte Architektur integrierter Informationssysteme 
(ARIS; vgl. Scheer (1997, 2001, 2002)) ist ein Rahmenkonzept für die ganz- 
heitliche Modellierung von betrieblichen Informationssystemen bzw. der ge- 
samten Informationsverarbeitung eines Unternehmens vom Fachkonzept bis 
zur Implementierung. ARIS verfolgt dabei einen prozessorientierten Ansatz, 
indem die Modellierung von Geschäftsprozessen als Grundlage für die Gestal- 
tung, Implementierung und Optimierung entsprechender Geschäftsprozesse 
in den Mittelpunkt gestellt wird. 
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Die Beschreibung von Geschäftsprozessen basiert auf einem allgemeinen 
Geschäftsprozessmodell, das auf der Metaebene die relevanten Modellierungs- 
konstrukte festlegt; vgl. Abbildung 4.1. Zwischen Ausprägungen der Mo- 
dellierungskonstrukte können verschiedene Zusammenhänge („Flüsse“) be- 
stehen, die über entsprechende Kanten bzw. Pfeile dargestellt werden. In 
Abbildung 4.2 ist beispielhaft ein Ausschnitt eines anwendungsspezifischen 
Geschäftsprozessmodells dargestellt. Entsprechende Geschäftsprozessmodel- 
le können auch mittels der von Scheer (1990a) beschriebenen Vorgangsket- 
tendiagramme veranschaulicht werden, wobei eine darstellungstechnisch ta- 
bellarische Orientierung an den verschiedenen Sichten erfolgt. Aufgrund der 
Vielfalt der modellierten Aspekte werden solche Geschäftsprozessmodelle je- 
doch relativ schnell kompliziert. 




Legende: 



Organisations-ZRessourcenfluss 

Kontrollfluss 

Informationsfluss 

Informationsdienstleistungsfluss 

Sachleistungsfluss 

Finanzmittelfluss 



Abbildung 4.1. Allgemeines ARIS-Geschäftsprozessmodell; Quelle: Scheer (2002, 
S. 31) 
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Abbildung 4.2. Beispiel für ein Geschäftsprozessmodell in ARIS (Ausschnitt); 
nach Scheer (2002, S. 28) 



Kernelemente des ARIS-Geschäftsprozessmodells sind Funktionen. Funk- 
tionen werden durch Ereignisse bzw. entsprechende Nachrichten ausgelöst; 
die Verrichtung einer Funktion führt in der Regel zu Folgeereignissen bzw. 
zu entsprechenden Nachrichten. Die Zusammenhänge zwischen Funktionen, 
Nachrichten und Ereignissen bestimmen den Kontrollfluss von Geschäftspro- 
zessen. Die Zuordnung von für Funktionen verantwortlichen Organisations- 
einheiten bzw. für die Funktionsausführung notwendigen Ressourcen verschie- 
dener Art wird als Organisations- bzw. Ressourcenfluss bezeichnet. Die ein- 
und ausgehenden Daten von Funktionen bestimmen einen entsprechenden In- 
formationsfluss. Hierbei kann es sich einerseits um ein- und ausgehende Nach- 
richten im Zusammenhang mit entsprechenden Ereignissen handeln, anderer- 
seits können im Rahmen der Funktionsausführung weitere (Umfeld-)Daten 
benötigt und gegebenenfalls verändert werden. Darüber hinaus können Funk- 
tionen eine zugeordnete Zielsetzung sowie eingehende und resultierende Leis- 
tungen verschiedener Art zugeordnet werden. Hierbei wird in Informations- 
dienstleistungen, sonstige immaterielle Dienstleistungen, Sachleistungen so- 
wie in Finanzmittel unterschieden. Die Zusammenhänge zwischen Funktionen 
sowie eingehenden und resultierenden Leistungen bilden den Leistungsfluss 
eines Geschäftsprozesses, der in die verschiedenen Leistungsarten differenziert 
werden kann. 
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Da die Darstellung aller beschriebenen Modellaspekte relativ schnell zu 
unübersichtlichen und kaum handhabbaren Modellen führt, beinhaltet ARIS 
eine Strukturierung in verschiedene Sichten; vgl. das in Abbildung 4.3 ge- 
zeigte so genannte ARIS-Haus. Die Daten-, Organisations-, Funktions- und 
Leistungssicht werden in einer Steuerungssicht verknüpft. Diese Steuerungs- 
sicht beschreibt über den Kontrollfluss die eigentlichen dynamischen Aspekte 
eines Geschäftsprozessablaufes und stellt dabei Verbindungen zwischen den 
anderen, eher statischen Sichten her. 




Abbildung 4.3. Die Sichten des so genannten ARIS-Hauses; nach Scheer (2002, 
S. 37) 



Neben der Betrachtung gemäß verschiedener Sichten beinhaltet das ARIS- 
Rahmenkonzept ebenfalls eine Gliederung bezüglich der Nähe zur Informati- 
onstechnik über die Ebenen Fachkonzept, DV-Konzept und Implementierung', 
vgl. Abschnitt 4.1.1, S. 96. Das heißt, für jede Sicht können Modelle entspre- 
chend der typischen Phasen des Entwicklungslebenszyklus auf den verschie- 
denen Ebenen gebildet werden. 

Prinzipiell können in den verschiedenen Sichten und Ebenen im Sinne 
des Rahmenkonzept- Ansatzes von ARIS verschiedene Metamodelle bzw. kon- 
krete Modellierungsmethoden Verwendung finden; vgl. die Abschnitte 4.2 
bis 4.4. Eine entsprechende Auswahl ist abhängig vom verfolgten Modellie- 
rungszweck und den hierdurch implizierten Anforderungen. Weiterhin ist ei- 
ne Unterstützung durch Softwarewerkzeuge wesentlich.'* Im Zusammenhang 

Vgl. das ARIS Toolset der IDS Scheer AG. 



4.1 Unternehmensmodellierung 101 



mit ARIS kamen in der Vergangenheit insbesondere erweiterte Formen der 
Entity-Relationship-Modellierung (vgl. Abschnitt 4.2.1) für die Datensicht 
sowie Ereignisgesteuerte Prozessketten (vgl. Abschnitt 4.4.2) für die Steue- 
rungssicht zum Einsatz, wobei hier jeweils der Schwerpunkt auf die Fachkon- 
zeptebene gelegt wird. Inzwischen werden die verschiedenen Sichten teilweise 
auch auf der Grundlage der objektorientierten Unified Modeling Language 
modelliert; vgl. Abschnitt 4.5. 

Das wesentliche Ziel eines ganzheitlichen Geschäftsprozessmanagements 
ist eine Unterstützung aller Entwicklungsphasen im Lebenszyklus von 
Geschäftsprozessen. Hierfür beschreibt Scheer (2002) unter dem Begriff ARIS 
HOBE (House of Business Engineering) vier miteinander verknüpfte Anwen- 
dungsfelder. Grundlegend geht es um die eigentliche Prozessgestaltung, die 
beispielsweise durch die simulative Bewertung von Prozessen auf der Basis 
entsprechender Prozessmodelle unterstützt werden kann. Eng hiermit ver- 
knüpft ist die operative Prozessplanung, -Steuerung und -kontrolle, die eine 
entsprechende Rückkopplung auf die eigentliche Prozessgestaltung mit sich 
bringen kann. Wesentlich ist hierfür die direkte Nutzung von Geschäftspro- 
zessmodellen zur Konfiguration und Steuerung von Workflow-Systemen; vgl. 
Abschnitt 7.1.4. Außerdem können Geschäftsprozessmodelle im Rahmen des 
Gustomizing von betriebswirtschaftlichen Standardsoftwaresystemen genutzt 
werden. Dies ist insbesondere dann zweckmäßig, wenn ein softwaregestützter 
und damit automatisierter Abgleich mit entsprechenden Referenzmodellen 
des Standardsoftwaresystems möglich ist. 

4.1.3 Referenzmodelle 

Konkrete, aber vom Einzelfall abstrahierte Modelle zur Darstellung eines 
standardisierten Wirklichkeitsausschnittes mit dem Gestaltungsanspruch ei- 
nes Soll-Modells bezeichnet man als Referenzmodell. Referenzmodelle werden 
im Rahmen der Unternehmensmodellierung insbesondere zur Beschreibung 
idealtypischer betriebswirtschaftlicher Fachinhalte bzw. entsprechender Infor- 
mationssysteme verwendet; vgl. Becker et al. (1999). Referenzmodelle zeigen 
etwa auf, wie ein Unternehmensmodell aufgebaut sein könnte, indem ide- 
altypische Strukturen und Abläufe dargestellt werden (ggf. branchen- oder 
länderbezogen). Durch einen Vergleich vorhandener Unternehmensmodelle 
mit einem Referenzmodell können Unterschiede zu (vermeintlich?) idealen 
Strukturen oder Abläufen offenbar werden. Diese Unterschiede können dann 
ggf. im Sinne eines „Benchmarkings“ als Grundlage einer Entscheidung zu 
organisatorischen Veränderungen dienen. Damit können Referenzmodelle Er- 
klärungscharakter besitzen, da Aspekte eines idealtypischen Unternehmens 
mit den relevanten technischen und betriebswirtschaftlichen Wirkungsbezie- 
hungen abgebildet werden; vgl. Keller (1993, S. 55). 

Referenzmodelle können zur Lösung bzw. Vereinfachung konkreter Ge- 
staltungsaufgaben eingesetzt werden, indem die Unternehmensmodellierung 
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Über eine Anpassung der Referenzmodelle erfolgt. Ausgehend von den im Re- 
ferenzmodell abgebildeten Objekten (wie Daten, Funktionen, Prozessen oder 
Organisationseinheiten) und deren Beziehungen zueinander kann durch An- 
passungen ein spezielles Unternehmen modelliert werden. Eine diesbezügliche 
Vorgehensweise ist insbesondere im Zusammenhang mit dem Einsatz von 
betriebswirtschaftlichen Standardsoftwaresystemen zweckmäßig, sofern das 
Standardsoftwaresystem auf einem entsprechenden Referenzmodell basiert. 
Die notwendigen Anpassungen des Referenzmodells deuten dann auf Anpas- 
sungserfordernisse hin (Customizing) . 

Generell stellt sich jedoch die Frage, inwieweit sich ein spezifisches Unter- 
nehmen in ein Referenzmodell einordnen lässt. Die Unternehmensspezifität 
erscheint insbesondere hinsichtlich der prozessorientierten Sicht in der Regel 
erheblich. Bei der Verwendung nur eingeschränkt anpassbarer Referenzmodel- 
le bzw. entsprechender Standardsoftwaresystemen stellt sich die Problematik 
hinsichtlich des möglichen Verlustes von Wettbewerbsvorteilen. 

Aufgrund der unterschiedlichen Zielsetzungen und Anwendungsgebiete 
sind für die Abbildung eines Unternehmens verschiedenartige Referenzmo- 
delle entwickelt worden. Im Folgenden sei kurz auf zwei bekannte Referenz- 
modelle hingewiesen. 

Das so genannte Kölner Integrationsmodell von Grochla (1974) stellt die 
Funktionen in den Vordergrund, indem die sachlogischen Verknüpfungen zwi- 
schen unterschiedlichen Unternehmensaufgaben verdeutlicht werden; vgl. Ab- 
bildung 4.4. Aufgaben werden hierbei in Form von Rechtecken, in das Modell 
ein- oder ausgehende Daten in Form von abgerundeten Rechtecken und son- 
stige Daten als Parallelogramme graphisch modelliert. Beziehungen werden 
durch Pfeile (so genannte Kanäle) dargestellt. Um Unübersichtlichkeiten zu 
vermeiden, gibt es darüber hinaus Konnektoren (in Form von Quadraten 
bzw. Kreisen). Für die genauere Beschreibung dieser Elemente werden eine 
Aufgabenbeschreibungsliste, eine Kanalbeschreibungsliste und eine Konnek- 
torenbeschreibungsliste verwendet. Eine Zuordnung von Elementen der Lis- 
ten und der Graphik findet über das Koordinatensystem der Graphik (für 
Aufgaben und Daten) oder über eine gesonderte Nummerierung (für Kanäle 
und Konnektoren) statt. 

Das wesentliche Ziel des Unternehmensdatenmodells (UDM) von Scheer 
(1990b) besteht darin, Datenverflechtungen innerhalb eines Unternehmens 
(insbesondere eines Industriebetriebes) über die Abteilungs- und Anwen- 
dungsebene hinweg aufzuzeigen. Somit ist die in Abschnitt 4.1.1 beschriebene 
Datenintegration ein wichtiges Ziel dieses Referenzmodells. Die graphische 
Darstellung erfolgt mit Hilfe eines erweiterten Entity-Relationship-Modells; 
vgl. hierzu Abschnitt 4.2.1. 

4.1.4 Modellierungsprinzipien 

Eine Modellbildung ist oftmals als ein komplexer, kreativer Prozess zu be- 
trachten, der nur eingeschränkt auf der Basis objektiver, formaler Regeln 
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Abbildung 4.4. Integrationsmodell von Grochla; vgl. Grochla (1974), Faltblatt 3 



abläuft und damit in der Regel nicht automatisierbar ist. Es stellt sich die 
Frage, inwieweit entsprechende methodeninhärente Freiheitsgrade über all- 
gemeine Gestaltungsempfehlungen und Konventionen eingeschränkt werden 
können, um die EfRzienz der Modellierung und die semantische Qualität re- 
sultierender Modelle zu steigern. 

Becker et al. (1995) entwickeln Grundsätze ordnungsmäßiger Modellie- 
rung (GoM) im Hinblick auf sechs allgemeine Qualitätskategorien für die 
Modellierung bzw. entsprechende Modelle: 

• Richtigkeit 

Die Richtigkeit eines Modells kann einerseits bezüglich der Konformität zu 
dem zugrunde gelegten Metamodell beurteilt werden. Neben diesem syn- 
taktischen Kriterium stellt sich andererseits die Frage nach der semanti- 
schen Richtigkeit im Sinne eines Homomorphismus bezüglich Struktur und 
Verhalten des Modellierungsgegenstands. Während eine syntaktische Rich- 
tigkeit häufig relativ einfach verifiziert werden kann, stellt die semantische 
Validierung in der Regel ein komplexes Problem dar. 

• Relevanz 

In einem Modell sollten nur relevante Aspekte abgebildet werden. Die Re- 
levanz ist offensichtlich abhängig von dem Modellierungszweck. 

• Wirtschaftlichkeit 

Die Wirtschaftlichkeit einer Modellierung ist ebenfalls von dem Modellie- 
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rungszweck und einem entsprechenden Nutzenpotenzial abhängig. Außer- 
dem beeinflusst beispielsweise eine absehbare Veränderungshäuflgkeit den 
zweckmäßigen Detaillierungsgrad eines Modells. Der Aufwand einer Mo- 
dellerstellung kann durch die Verwendung geeigneter Softwarewerkzeuge 
und gegebenenfalls durch das Anpassen möglichst robuster Referenzmo- 
delle gesenkt werden. 

• Klarheit 

Über das Kriterium der Klarheit soll ein möglichst objektives Modell- 
verständnis gewährleistet werden. Eine beispielhafte Maßnahme ist die 
Verwendung klarer Begrifflichkeiten (über entsprechende Namenskonven- 
tionen bzw. Fachterminologien) unter Berücksichtigung der angenomme- 
nen Modellnutzer. Außerdem ist auf ästhetische Kriterien wie Lesbarkeit, 
Anschaulichkeit und Layout zu achten. 

• Vergleichbarkeit 

Die Vergleichbarkeit verschiedener Modelle wird durch die Verwen- 
dung desselben Metamodells bzw. kompatibler Modellierungsmethoden 
ermöglicht. Andernfalls sind entsprechende Transformationsregeln erfor- 
derlich. 

• Systematischer Außau 

Zur Reduktion von Modellkomplexität erfolgt die Modellierung häufig über 
verschiedene Sichten sowie auf unterschiedlichen Detaillierungs- und Be- 
trachtungsebenen. In diesem Zusammenhang ist ein systematischer Aufbau 
erforderlich, um eine strukturierte Integration der Modelle zu gewährlei- 
sten. 

Diese allgemeinen Grundsätze können für spezifische Modellierungszwecke 
bzw. entsprechende Sichten und Methoden konkretisiert werden; vgl. z. B. 
Becker und Schütte (2004, Abschnitt 2.5). 

Im Hinblick auf eine zielgerichtete und systematische Gestaltung von Sys- 
temen in verschiedenen Anwendungsbereichen stellen sich Maier und Rechtin 
(2000) der Aufgabe, unabhängig vom jeweiligen Anwendungsbereich Gemein- 
samkeiten von Systemen zu identifizieren und auf dieser Basis generelle Er- 
klärungs- und Gestaltungsmuster für Systemarchitekturen abzuleiten. Offen- 
sichtlich besteht ein enger Zusammenhang zur Modellierung entsprechender 
Systeme. Einige Beispiele für generelle Prinzipien der Systemgestaltung sind 
das kritische Hinterfragen des betrachteten Problems bzw. von Anforderun- 
gen, die Modularisierung des Systems, das Offenhalten von Gestaltungsop- 
tionen sowie das Schaffen möglichst einfach strukturierter Modelle bzw. Sys- 
teme. 

Pidd (2003) formuliert die folgenden schlagwort artigen Ratschläge für die 
Modellbildung: 

• Modelliere einfach - denke kompliziert! 

• Beginne klein und erweitere! 

• Teile und herrsche, vermeide Megamodelle! 

• Nutze Metaphern, Analogien und Ähnlichkeiten! 
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• Verliehe dich nicht in Daten! 

Es wird deutlich, dass das Vermeiden unnötiger Kompliziertheit ein wesent- 
liches Erfolgskriterium bei der Modellierung darzustellen scheint. 



4.2 Datenmodellierung 

Datenmodelle dienen der Herstellung einer Abstraktion zum Zwecke einer 
datenorientierten Beschreibung der Objekte eines Wirklichkeitsausschnittes. 
Datenstrukturen sind relativ beständige Elemente von Unternehmen und da- 
mit in der Regel eine vergleichsweise stabile Komponente von Anwendungs- 
systemen. Daher ist die Modellierung der Unternehmensdaten ein grundle- 
gender Teil der gesamten Unternehmensmodellierung. Durch die Schaffung 
eines einheitlichen und konsistenten Datenmodells und einer entsprechenden 
Umsetzung in Datenbanken sind verschiedene Sichtweisen und Zugriffe auf 
diese Daten möglich, so dass eine effiziente Verwaltung großer Datenbestände 
erreicht werden kann; vgl. Kapitel 5. 

Aus einer historischen Sichtweise heraus wurden Datenstrukturen 
zunächst primär isoliert im Zusammenhang mit Algorithmen, die auf entspre- 
chenden Daten operieren, definiert. Der wesentliche Nachteil dieser primär 
funktionsorientiert ausgerichteten Vorgehensweise besteht in der fehlenden 
integrativen Gesamtsicht auf die Unternehmensdaten, was zu Redundanzen 
und Inkonsistenzen in der Datenhaltung führen kann. Heute werden die Daten 
betriebswirtschaftlicher Anwendungssysteme zunehmend anwendungsüber- 
greifend verwaltet und genutzt, was entsprechende integrierte Datenmodelle 
voraussetzt. In diesem Zusammenhang bietet sich ein primär datenorientier- 
ter Entwicklungsprozess an; vgl. Vetter (1998). 

Eine semantische Datenmodellierung basiert im Wesentlichen auf der 
Anwendung einiger weniger grundlegender Abstraktionsmechanismen (Kon- 
struktionsoperatoren), die im Folgenden kurz charakterisiert werden: 

• Die Klassifikation ( Typisierung) dient der Zusammenfassung von Objekten 
mit gleichartigen Eigenschaften (Attributen) zu einem Objekttyp (Klasse). 
Beispielsweise können die Objekte roter Golf, blauer Volvo, schwarzer Por- 
sche zu einer Klasse Auto zusammengefasst werden, die u. a. die Attribute 
Farbe und Marke besitzt. 

• Mit dem Konstrukt der Generalisierung ( Verallgemeinerung) bzw. Spezia- 
lisierung werden Teilmengenbeziehungen zwischen verschiedenen Klassen 
definiert. Die Klassen Fathrrad, Auto und Lastkraftwagen sind z. B. jeweils 
ein Spezialfall der Klasse Fahrzeug (und diese Klasse eine Verallgemeine- 
rung der anderen drei Klassen). 

• Im Rahmen der Gruppierung (Sammlung) werden konkrete Objekte des 
gleichen Typs zu einer größeren Einheit zusammengefasst. Ein Beispiel ist 
die Zusammenfassung von Arbeitsplätzen zu einer Abteilung. 
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• Bei der Aggregation werden mehrere Objekte (verschiedener Klassen) zu 
einer neuen, komplexeren Klasse zusammengesetzt, wobei die eingehenden 
Objekte die Rolle von Komponenten übernehmen. Als Beispiel sei hier 
eine Aggregation im Zusammenhang mit den Klassen Motor, Karosserie, 
Rad und anderen zur Klasse Auto genannt. In diesem Sinne kann man 
die Aggregation als Transformation einer Beziehung in eine neue Klasse 
verstehen. 

Entsprechende Zusammenhänge sollten in Datenmodellen geeignet abgebildet 
werden können. Für die Datenmodellierung gibt es unterschiedliche Model- 
lierungsmethoden, wobei auf der Fachkonzeptebene insbesondere die Entity- 
Relationship-Modellierung und ihre Erweiterungen sowie in jüngerer Zeit ent- 
sprechende Teile der Unified Modeling Language (UML) von Bedeutung sind. 
In Folgenden wird das Entity-Relationship-Modell mit einigen Erweiterungen 
näher betrachtet; zur UML vgl. Abschnitt 4.5. 

4.2.1 Das Entity-Relationship-Modell 

„This model incorporates some of the important semantic informa- 
tion about the real world. [. . .] The entity-relationship model adopts 
the [. . .] view that the real world consists of entities and relation- 
ships.“ (Chen (1976)) 

Das Entity-Relationship-Modell (ER-Modell) ist eine graphische Modellie- 
rungstechnik zur Darstellung von Objekten (Entitys) und ihrer Beziehungen 
{Relationship s), das von Chen (1976) entwickelt wurde. Das ER-Modell ist 
damit ein Werkzeug zur semantischen, konzeptionellen Datenmodellierung 
(insbesondere im Rahmen des Entwurfs von Datenbanken oder der Unter- 
nehmensdatenmodellierung). Bis heute wurde es durch verschiedene Modi- 
fikationen und Ergänzungen weiterentwickelt. Die ER-Modellierung ist in 
der Praxis weit verbreitet, da es sich einerseits um eine einfach verständ- 
liche Modellierungstechnik handelt, mit der reale Gegenstandsbereiche in ei- 
ner zweckmäßigen Form abgebildet werden können. Andererseits lassen sich 
ER-Modelle relativ einfach in relationale Datenmodelle überführen, die im 
Zusammenhang mit relationalen Datenbanksystemen zum Einsatz kommen; 
vgl. Abschnitt 5.3. 

Entitys (Objekte) sind wohlunterscheidbare reale oder abstrakte Dinge, 
die für das betrachtete Objektsystem relevant sind. Synonym werden für den 
Begriff Entity auch die Begriffe Entität, Objekt, Objektausprägung, Exemp- 
lar oder Instanz verwendet. Entitys mit gleichartigen relevanten Eigenschaf- 
ten werden zu Entitytypen (Objekttypen, Klassen) zusammengefasst (Klas- 
sifizierung). Entitys besitzen Eigenschaften (Attribute) mit einem Wertebe- 
reich {Domain). Zu jedem Entitytyp gehört ein (Primär-) Schlüssel, d. h. ein 
Attribut (oder eine Attributkombination), dessen Attributwert (bzw. deren 
Kombination von Attributwerten) ein Entity eindeutig identifiziert. In der 
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graphischen Darstellung des ER-Modells werden Entitytypen durch Recht- 
ecke, Attribute durch Ellipsen und Schlüsselattribute unterstrichen darge- 
stellt. Als Beispiel betrachten wir den Entitytyp Buch eines Datenmodells ei- 
ner Bibliothek, dargestellt in Abbildung 4.5. Jedes Objekt dieses Entitytyps, 
d. h. jedes konkrete Buch, besitzt Werte für die Attribute Inventarnummer, 
Erstautor, Titel, Verlag sowie (Erscheinungs-) Jahr, wobei die Identifikation 
durch die Inventarnummer erfolgt (d. h. diese muss für jedes einzelne Buch 
einen anderen Wert besitzen). 




Mittels Beziehungstypen werden Beziehungen zwischen Entitys (bzw. En- 
titytypen) dargestellt. Dabei bezeichnet man die Anzahl beteiligter Entityty- 
pen als den Grad eines Beziehungstyps. Die graphische Darstellung von Be- 
ziehungen geschieht mittels Rauten für Beziehungstypen. Auch hier werden 
Attribute durch Ellipsen dargestellt. Abbildung 4.6 zeigt den Beziehungstyp 
Ausleihe, der den entsprechenden Zusammenhang zwischen Büchern und 
Lesern (dargestellt durch die Entitytypen Leser und Buch) aufzeigt und das 
Attribut Rückgabedatum besitzt. 




Abbildung 4.6. Beziehungstyp Ausleihe 



Komplexe Beziehungstypen sind kontextabhängig auch als Entitytypen 
auffassbar und modellierbar. Dies gilt beispielsweise für Beziehungstypen 
höheren Grades sowie für attributierte Beziehungstypen (insbesondere bei 
identifizierenden Attributen). In der graphischen Darstellung wird ein als 
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Entitytyp uminterpretierter Beziehungstyp teilweise durch ein Rechteck mit 
eingeschlossener Raute kenntlich gemacht. 

Entitytypen können in unterschiedlicher Beziehung zueinander stehen und 
je nach Beziehung verschiedene Rollen einnehmen. Dabei ist auch die Abbil- 
dung rekursiver Beziehungen möglich. So kann der Entitytyp Person sowohl 
im Rahmen einer Vater-Sohn-Beziehung als auch einer Chef-Angestellten- 
Beziehung verwendet werden, wobei in beiden Fällen der Entitytyp Person 
zweimal an der Beziehung beteiligt ist; siehe Abbildung 4.7 (zur eindeutigen 
Identifikation können die Kanten in der Abbildung durch die jeweilige Rolle 
bezeichnet werden). 




Abbildung 4.7. Beziehungstypen Vater-Sohn und Chef -Angestellter 



Die Kardinalität eines Beziehungstyps sagt aus, mit wie vielen anderen 
Objekten ein Objekt eines bestimmten Typs in einer konkreten Beziehung 
stehen kann. Diese (so definierte) Kardinalität kann sinnvoll nur für binäre 
Beziehungen angegeben werden (d. h. nur für Beziehungen zwischen zwei En- 
titytypen). In Abhängigkeit von der Kardinalität kann man drei Arten von 
Beziehungstypen bilden: 

• 1:1 

Jedes Entity des ersten Entitytyps steht mit genau einem Entity des zwei- 
ten Entitytyps in einer spezifizierten Beziehung und umgekehrt. 

• l:n 

Jedes Entity des ersten Entitytyps kann mit mehreren Entitys des zweiten 
Entitytyps in einer spezifizierten Beziehung stehen, jedes Entity des zweiten 
Entitytyps jedoch nur mit einem Entity des ersten Entitytyps. 

• m:n 

Jedes Entity des ersten Entitytyps kann mit mehreren Entitys des zweiten 
Entitytyps in einer spezifizierten Beziehung stehen und umgekehrt (d. h. es 
gibt keine Restriktionen). 

Die Abbildungen 4.8 und 4.9 veranschaulichen die Kardinalität von Be- 
ziehungstypen wiederum am Beispiel einer Bibliothek. Jeder Leser besitzt 
genau eine Magnetkarte und jede Magnetkarte ist exakt einem Leser zu- 
geordnet, so dass sich ein 1 : 1-Beziehungstyp ergibt. Dagegen kann ein Le- 
ser mehrere Bücher gleichzeitig ausleihen, jedes Buch kann jedoch nur von 
höchstens einem Leser entliehen werden, so dass der Beziehungstyp Ausleihe 
die Kardinalität l:n besitzt. Hierbei muss ein konkretes Entity nicht an ei- 
nem Beziehungstyp beteiligt sein, was in Abbildung 4.9 verdeutlicht wird. Da 
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ein Leser sowohl mehrere Bücher bestellen kann, wie auch ein Buch gleich- 
zeitig von mehreren Lesern bestellt werden kann, liegt in diesem Fall ein 
m:n-Beziehungstyp vor. 




Abbildung 4.8. Kardinalitäten von Beziehungstypen, Teil 1 




l:l-Beziehung 



1 :n-Beziehung 



m:n-Beziehung 



Abbildung 4.9. Kardinalitäten von Beziehungstypen, Teil 2 



Neben der Kardinalität gibt es weitere gebräuchliche Formen der Spe- 
zifikation der zulässigen Anzahl beteiligter Entitys an einem Beziehungstyp. 
So bietet die Verwendung der (mm,max)-Notation eine semantisch erweiterte 
Möglichkeit zur Festlegung der hier so genannten Beziehungskomplexität, was 
zu entsprechenden Integritätsbedingungen für die Datenbank- bzw. Anwen- 
dungssystementwicklung führen kann. Besitzt ein Entitytyp im Zusammen- 
hang mit einem Beziehungstyp eine Beziehungskomplexität von (min,max), 
so wird hiermit ausgedrückt, dass ein Entity des Entitytyps an der Bezie- 
hung mindestens mm-mal teilnehmen muss und höchstens max-mal teilneh- 
men darf. Falls der Wert max nicht bekannt ist (bzw. beliebig groß werden 
kann), so wird dies durch das Sternsymbol („*“) dargestellt. Für die aus Ab- 
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bildung 4.8 bekannten Beziehungstypen werden die Beziehungskomplexitäten 
in Abbildung 4.10 veranschaulicht.^ Durch diese Darstellung kann auch ge- 
zeigt werden, ob ein Entity in einer Beziehung unbedingt Vorkommen muss, 
indem der Wert min größer als Null gesetzt wird (wie im Beispiel für den 
Beziehungstyp besitzt und den Entitytyp Leser). 




Abbildung 4.10. Komplexitäten von Beziehungstypen 



In der Abbildung 4.11 ist ein Beispiel für einen ternären Beziehungstyp 
dargestellt; vgl. Heuer und Saake (2000). Das Modell bildet Buchempfeh- 
lungen von Professoren für Vorlesungen ab. Ein Ersetzen des ternären Be- 
ziehungstyps durch drei binäre Beziehungstypen zwischen jeweils zwei der 
beteiligten Entitytypen ist nicht sinnvoll, da dies zu einem Informationsver- 
lust führen würde (der Zusammenhang, welches Buch für welche Vorlesung 
von wem empfohlen wird, ginge verloren). Möglich wäre dagegen die Inter- 
pretation des Beziehungstyps Empfehlung als Entityttyp mit drei binären 
Beziehungstypen in Verbindung mit den jeweiligen Entityttypen. Die Se- 
mantik der Modellierung von Kardinalitäten bzw. Beziehungskomplexitäten 
für ternäre Beziehungstypen (bzw. allgemein für Beziehungstypen mit einem 
Grad größer als zwei) ist interpretationsbedürftig; vgl. Genova et al. (2001). 
Die angegebenen Beziehungskomplexitäten drücken aus, wie häufig ein Entity 
des jeweiligen Entitytyps an einer Beziehung teilnehmen muss und kann. Die 
einzige modellierte Einschränkung bezieht sich darauf, dass für jede Vorlesung 
mindestens eine Buchempfehlung vorliegen muss. Die eingeführte Form der 
Beziehungskomplexitäten ermöglicht es dagegen beispielsweise nicht, Bedin- 
gungen der Art „Ein Professor muss für eine Vorlesung zwei bis fünf Bücher 
empfehlen“ abzubilden; hierfür wäre ein erweitertes Konzept erforderlich; vgl. 
McAllister (1998). 

® Es sei darauf hingewiesen, dass neben der hier verwendeten, so genannten bezie- 
hungszählenden graphischen Darstellung (zurückgehend auf Rochfeld und Tar- 
dieu (1983)) auch die objektzählende Darstellung gebräuchlich ist, bei der die 
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Abbildung 4.11. Ternärer Beziehungstyp Empfehlung 



4.2.2 Erweiterungen des Entity-Relationship-Modells 

Aufbauend auf den bisher vorgestellten Basiskonstrukten des ER-Modells, die 
im Wesentlichen zwei Formen der Klassifikation (Typisierung) - nämlich von 
Entitys und Beziehungen - ermöglichen, wurden diverse Erweiterungen ent- 
wickelt, durch die die semantischen Ausdrucksmöglichkeiten erweitert werden 
sollen. Eine derartige Erweiterung ist die IS-A-Beziehung, die zur Darstel- 
lung der Generalisierung bzw. Spezialisierung und somit zur Beschreibung 
von Teilmengenbeziehungen zwischen Entity typen verwendet werden kann. 
Graphisch wird eine IS-A-Beziehung wie ein einfacher Beziehungstyp mittels 
einer Raute mit dem Eintrag „IS-A“ dargestellt, wobei ein Pfeil zum allge- 
meineren Entitytyp führt. Die Entitytypen Pilot und Techniker sind bei 
der Modellierung einer Fluggesellschaft deren Angestellte, so dass der Enti- 
tytyp Fluggesellschaftsangestellter eine Verallgemeinerung der Typen 
Pilot und Techniker darstellt; vgl. Abbildung 4.12. 

Bei einer IS-A-Beziehung werden die Attribute vom allgemeinen auf spe- 
zialisierte Entitytypen vererbt. Dies bedeutet, dass alle generell vorhandenen 
Attribute beim allgemeineren Entitytypen angesiedelt werden, wohingegen 
die spezialisierten Entitytypen nur die genau für diesen Typ spezifischen At- 
tribute besitzen. Auch der Schlüssel kann vom allgemeineren auf die spe- 
zielleren Entitytypen vererbt werden, so dass diese keinen eigenen Schlüssel 
benötigen, da jedes Objekt eines spezialisierten Typs ebenfalls ein Objekt des 
generalisierten Typs ist. Im Beispiel aus Abbildung 4.12 bedeutet dies, dass 
ein Pilot bzw. ein Techniker nicht nur die Attribute Stunden und Lizenz bzw. 
Team-Nr besitzt, sondern aufgrund der IS-A-Beziehung zusätzlich auch die 
Attribute Pers-Nr, Name, Adresse sowie Beruf. Somit benötigen die beiden 
spezialisierten Entitytypen kein eigenes Schlüsselattribut, da der Schlüssel 
Pers-Nr infolge der IS-A-Beziehung auch auf diese beiden Entitytypen ver- 
erbt wird. 

Anordnung der Beziehungskomplexitäten vertauscht ist (was der oben verwen- 
deten Darstellung der Kardinalitäten gemäß Chen (1976) näher kommt). 
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Abbildung 4.12. Spezialisierung 



Eine Spezialisierung kann einerseits dahingehend klassifiziert werden, ob 
alle Spezialfälle zusammen den allgemeineren Entitytyp vollständig umfassen 
{totale Spezialisierung) oder nicht {partielle Spezialisierung). Andererseits 
kann eine Spezialisierung danach klassifiziert werden, ob ein konkretes Entity 
in höchstens einem spezialisierten Entitytypen enthalten sein kann {disjunkte 
Spezialisierung) oder nicht. Eine totale Spezialisierung ist in den Abbildungen 
4.13(a) und 4.14(b) dargestellt, wohingegen die Abbildungen 4.13(b) und 
4.14(a) jeweils partielle Spezialisierungen veranschaulichen. Die Buchstaben 
t bzw. p neben der IS-A-Beziehung symbolisieren eine totale bzw. partielle 
Spezialisierung, die disjunkt ist (d) oder nicht (n). Eine konkrete Person 
kann nur Mann oder Frau sein, nie jedoch beides, so dass die IS-A-Beziehung 
aus Abbildung 4.13(a) disjunkt ist (wie auch die Beziehung aus Abbildung 
4.14(a)). Dagegen kann eine konkrete Person sowohl zum Entitytypen Junge 
als auch zum Entitytypen Kind gehören, so dass diese Beziehung (Abbildung 
4.13(b)) nicht disjunkt ist, ebenso wie die in Abbildung 4.14(b) dargestellte 
Beziehung. 

Eine andere Erweiterung des ER-Modells ist die existenzielle Abhängig- 
keit. Diese wird verwendet, wenn so genannte schwache Objekte ohne die 
zugehörigen starken Objekte nicht existieren können. Die graphische Darstel- 
lung erfolgt mit einem dicken Pfeil vom starken zum schwachen Objekt. Ein 
Spezialfall der existenziellen Abhängigkeit ist die identifikatorische Abhängig- 
keit, die zusätzlich ausdrückt, dass zur eindeutigen Identifizierung des schwa- 
chen Objektes der Schlüssel des zugehörigen starken Objektes benötigt wird. 
Beim Beispiel einer Rechnung, die aus einem Rechnungskopf und mehreren 
Rechnungspositionen besteht, kann eine Rechnungsposition nicht ohne den 
Rechnungskopf existieren und benötigt zur eindeutigen Identifizierung auch 
dessen Attribut Rechnungs-Nr; vgl. Abbildung 4.15. 
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(a) (b) 

Abbildung 4.13. Spezialisierungstypen, Teil 1 




(a) (b) 

Abbildung 4.14. Spezialisierungstypen, Teil 2 




Abbildung 4.15. Identifikatorische Abhängigkeit 



Zur expliziten Abbildung des Abstraktionsmechanismus Aggregation, d. h. 
der Zusammenfassung von bestimmten Entitys zu einer größeren Einheit, 
sind verschiedene Erweiterungen des ER-Modells vorgeschlagen worden. In 
der Abbildung 4.16 sind zwei alternative Darstellungsformen veranschaulicht, 
die jeweils die Bildung eines Entitytyps Rechnung mit entsprechenden Kom- 
ponenten ausdrücken. 

Zusammenfassend ist festzuhalten, dass das ER-Modell eine graphische 
Darstellungsform zur konzeptionellen Beschreibung der Datensicht auf der 
Fachkonzeptebene ist.® Basiskonstrukte dieser Methode sind einerseits Enti- 
tys bzw. Entitytypen, die eine Bezeichnung, Attribute und hierunter einen 
identifizierenden Schlüssel (gegebenenfalls aus mehreren Attributen beste- 

® Die Umsetzung von ER-Modellen in implementierungstechnische Datenbankmo- 
delle wird in Kapitel 5 betrachtet. 
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Rechnung 




Abbildung 4.16. Aggregation 



hend) besitzen müssen und andererseits Beziehungen bzw. Beziehungstypen 
mit einer Deklaration einer Bezeichnung, der beteiligten Entitytypen, der At- 
tribute (soweit vorhanden) sowie von Kardinalitäten bzw. Beziehungskomple- 
xitäten. Erweiterungen sind z.B. Spezialisierungen von Entity-Deklarationen 
über IS-A-Beziehungen, die Aggregation sowie die Darstellung von existen- 
ziellen oder identifikatorischen Abhängigkeiten. Problematisch ist, dass ei- 
ne Reihe verschiedener Erweiterungen existieren, die sich sowohl bezüglich 
der Semantik als auch hinsichtlich der graphischen Darstellung teilweise un- 
terscheiden, was zu verschiedenen Erweiterten Entity-Relationship-Modellen 
geführt hat; vgl. z.B. Thalheim (2000). 

Als Beispiel für ein umfangreicheres ER-Modell betrachten wir ein aus- 
schnittsweises Datenmodell einer Fluggesellschaft; vgl. Vossen (2000). Als 
Objekte in diesem Realitätsausschnitt existieren Flugzeuge, Flugzeugtypen, 
Angestellte der Fluggesellschaft (mit bestimmten Kenntnissen bzw. Aufga- 
ben), Piloten, Techniker, Flüge, konkrete Abflüge und Passagiere. Die Zu- 
sammenhänge zwischen diesen Objekten sind in Abbildung 4.17 dargestellt, 
wobei Kardinalitäten sowie die meisten Attribute aus Gründen der Übersicht- 
lichkeit nicht angegeben wurden. Mit Hilfe dieser Abbildung wird deutlich, 
dass es oftmals sinnvoll ist, zweckabhängig auch vereinfachte Ausschnitte der 
Realität zu betrachten, da das ER-Modell ansonsten sehr umfangreich und 
damit unübersichtlich werden kann. 

Eine Besonderheit dieses Modells besteht darin, dass die Wartung eines 
Flugzeuges durch Techniker nicht als Beziehungstyp dargestellt wird (wie 
z.B. die Tätigkeiten „Passagier bucht Flug“ und „Pilot fliegt Abflug“), son- 
dern als Entitytyp modelliert wird. Der Grund hierfür ist, dass die Wartung 
nicht eindeutig durch den (bzw. die) Techniker und das zu wartende Flug- 
zeug identifiziert werden kann, wenn man davon ausgeht, dass ein Techniker 
ein Flugzeug innerhalb mehrerer Zeiträume warten kann (z.B. im Januar 
und, nach einer Pause im Februar, dann wieder im März) und entsprechende 
historische Informationen abgebildet werden sollen. Zur Identifikation einer 
konkreten Wartung wird eine eindeutige Wartungsnummer verwendet. Eine 
weitere Besonderheit dieses ER-Modells ergibt sich dadurch, dass der En- 
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Abbildung 4.17. Datenmodell einer Fluggesellschaft (Ausschnitt) 



titytyp Abflug identifikatorisch vom Entitytyp Flug abhängt, da allein das 
Datum des Abfluges nicht zur eindeutigen Identifizierung ausreicht (wenn 
man sinnvollerweise davon ausgeht, dass an einem Tag mehr als ein einziger 
Start der Fluggesellschaft stattflnden kann). 



4.3 Organisationsmodellierung 

Im Rahmen der Organisationsmodellierung werden im Wesentlichen stati- 
sche Unternehmensstrukturen im Sinne der Aufbauorganisation betrachtet 
(zur Ablauforganisation siehe den folgenden Abschnitt 4.4). Das heißt, aus- 
gehend vom institutionalen Organisationsbegriff bildet die Organisation als 
soziotechnisches System das Objektsystem der Modellierung. Die Organisa- 
tionssicht umfasst damit insbesondere die Gliederung von Organisationsein- 
heiten eines Unternehmens in kleinere Organisationseinheiten. Hinsichtlich 
personeller Aspekte führt dies zu elementaren Stellen im Sinne kleinster Or- 
ganisationseinheiten und deren Besetzung mit Personen, die entsprechende 
Rollen einnehmen. Vor dem Hintergrund der Abwicklung von Geschäftspro- 
zessen kann über Organisationsmodelle ausgedrückt werden, welche Orga- 
nisationseinheiten bzw. Rollen einzelnen Funktionen als Aufgabenträger zu- 
geordnet werden. Dies ist beispielsweise im Zusammenhang mit Workflow- 
Management-Systemen von großer Relevanz; vgl. Abschnitt 7.1.4. 

Für die Darstellung der reinen Gliederung von Organisationseinheiten 
sind Organigramme weit verbreitet. Einer Gliederung liegt jeweils ein be- 
stimmtes Gliederungsprinzip zugrunde. In Abhängigkeit von dem verfolgten 
Zweck kommen insbesondere das funktionale, das objektbezogene sowie das 
phasenbezogene Gliederungsprinzip zum Einsatz. Dies ist in Abbildung 4.18 
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beispielhaft veranschaulicht. Bei einer funktionalen Gliederung werden Or- 
ganisationseinheiten primär hinsichtlich disjunkter Tätigkeiten abgegrenzt. 
Dagegen führen objektbezogen gegliederte Organisationseinheiten prinzipiell 
gleiche oder ähnliche Tätigkeiten aus, dies jedoch für verschiedene Objekte 
(z.B. Vertriebsaufgaben für Produktgruppen, regional abgegrenzte Gebiete 
oder Kundensegmente). Bei der phasenbezogenen Gliederung werden Orga- 
nisationseinheiten gemäß des zeitlichen Ablaufs von Geschäftsprozessen an- 
geordnet. 




funktionale 

Gliederung 



objektbezogene 

Gliederung 



phasenbezogene 

Gliederung 



Abbildung 4.18. Organigramme gemäß verschiedener Gliederungsprinzipien 



In weitergehenden Organisationsmodellen kann beispielsweise abgebildet 
werden, an welchen Standorten Organisationseinheiten angesiedelt sind, wel- 
che Organisationseinheiten Stellen entsprechen und wie diese personell unter 
Beachtung von Anforderungsprofilen durch entsprechende Rollen einnehmen- 
de Mitarbeiter besetzt sind. Weiterhin können auch technische Aufgaben- 
träger und eine entsprechende Zuordnung von Ressourcen zu Organisations- 
einheiten einbezogen werden. Für eine nähere Betrachtung der Organisati- 
onsmodellierung sei z. B. auf Scheer (2001, Kapitel A.II.2) verwiesen. 

Im Hinblick auf die Gestaltung von Informationssystemen ist zu berück- 
sichtigen, dass sich ein Unternehmen nur teilweise durch die formalen Re- 
gelungen einer Organisationsstruktur bzw. entsprechende Modelle abbilden 
lässt. Häufig spielt die so genannte informelle Organisationskultur eine ent- 
scheidende Rolle für das Funktionieren eines Unternehmens. Dies muss in 
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Informationssystemen beispielsweise durch flexible Formen der Kommunika- 
tion und Prozessabwicklung Berücksichtigung Anden. 



4.4 Funktions- und prozessorientierte Modellierung 

Unter einer Funktion wird in einem abstrakten Sinne eine Transformation 
von Objekten über eine entsprechende Verrichtung im Hinblick auf eine Ziel- 
setzung verstanden. Als Objekte kommen grundsätzlich materielle Werkstof- 
fe, Informationen sowie Personen in Frage. Synonym zum Funktionsbegriff 
werden auch die Begriffe Aufgabe (aus dem Blickwinkel der Zielsetzung) 
oder Tätigkeit, Aktivität und Vorgang (aus dem Blickwinkel der Verrich- 
tung) verwendet. Funktionen können auf verschiedenen Detaillierungs- und 
Abstraktionsstufen betrachtet werden. Eine in einem bestimmten Kontext 
(z. B. betriebswirtschaftlich oder informationstechnisch) nicht mehr weiter 
sinnvoll untergliederbare Funktion wird als Elementarfunktion bezeichnet. 

Im Zusammenhang mit Funktionen versteht man unter einem ( Ge- 
schäfts- ) Prozess eine zusammengehörige Abfolge von zeitlich und sachlogisch 
gegliederten Funktionen zum Zwecke einer Leistungserstellung. In einer ent- 
sprechenden Prozesssicht steht der dynamische Ablauf (das Systemverhalten) 
im Mittelpunkt der Betrachtung. Die Modellierungskonstrukte Funktion und 
Prozess unterscheiden sich damit nur in der Art der Abstraktion. Einerseits 
können (Elementar-)Funktionen Elemente eines Geschäftsprozesses darstel- 
len. Andererseits können Funktionen als zusammenfassende und statische 
Betrachtung eines Geschäftsprozesses aufgefasst werden. 

In Abschnitt 4.4.1 werden verschiedene gebräuchliche Formen der Funk- 
tionsspeziflkation dargestellt (ohne Berücksichtigung der Prozesssicht). In 
Abschnitt 4.4.2 werden Ereignisgesteuerte Prozessketten als eine semi- 
formale Modellierungsmethode für die Geschäftsprozessmodellierung darge- 
stellt, während anschließend mittels Petri-Netzen eine formale Modellierungs- 
methode für die Prozesssicht betrachtet wird (Abschnitt 4.4.3). Im Zusam- 
menhang mit der objektorientierten Modellierung werden in Abschnitt 4.5.2 
weitere prozessorientierte Modellierungstechniken betrachtet. In diesem Zu- 
sammenhang ist anzumerken, dass sich bisher keine universelle Methode her- 
ausgebildet hat, die für alle möglichen Anwendungsbereiche der Geschäftspro- 
zessmodellierung (sei es die Anwendungssystementwicklung im engeren Sin- 
ne, das Workflow Management, das Gustomizing von Standardsoftware, 
die Geschäftsprozessoptimierung oder die Prozesskostenrechnung) uneinge- 
schränkt zweckmäßig ist. Offensichtlich ergeben sich sowohl in den ver- 
schiedenen Anwendungsbereichen als auch in den verschiedenen Phasen des 
Entwicklungs- bzw. Lebenszyklus von Systemen deutlich unterschiedliche An- 
forderungen, die hierauf abgestimmte Methoden erfordern. 
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4.4.1 Formen der Funktionsspezifikation 

Im Sinne der obigen Definition des FunktionsbegrifFs bestimmt eine Funkti- 
onsspezifikation die Transformation von Objekten. Eine solche Spezifikation 
beschreibt damit auf der Fachkonzeptebene primär das Problem („Was?“), 
während entsprechende Anforderungen in eine Umsetzung bzw. Implemen- 
tierung im Sinne der Problemlösung („Wie?“) überführt werden müssen.^ 
Die Spezifikation komplexer Funktionen beinhaltet im Sinne der Problem- 
dekomposition häufig eine Gliederung von Funktionen in Teilfunktionen. In 
Abbildung 4.19 ist eine dreistufige Funktionsgliederung über ein Funktions- 
hierarchiediagramm beispielhaft dargestellt. Bei der Erstellung eines entspre- 
chenden Modells kann sich sowohl eine Top-Down- als auch eine Bottom- 
C/p- Vorgehensweise eignen. Neben der funktionsorientierten Gliederung kann 
analog zur Organisationsmodellierung ebenfalls das objektbezogene sowie das 
phasenbezogene Gliederungsprinzip zugrunde gelegt werden. So können die 
in Abbildung 4.18 dargestellten Zusammenhänge unter Anpassung der Sym- 
bolik gleichfalls auch als Funktionsgliederungen aufgefasst werden. Eine pha- 
senbezogene Gliederung führt dabei bereits zu grundlegenden Teilstrukturen 
eines Prozessmodells. 




Abbildung 4.19. Funktionshierarchiediagramm 



^ Die Trennung zwischen Spezifikation und Implementierung ist bei den hier vor- 
nehmlich betrachteten informationstransformierenden Funktionen nicht immer 
deutlich, da insbesondere algorithmische Formen der Funktionsspezifikation ei- 
ner Implementierung als Software nahe kommen können. Dieser Zusammenhang 
ist so bei materialtransformierenden Funktionen nicht gegeben; beispielsweise 
ist die Spezifikation der Funktion „Bau eines bestimmten Gebäudes“ über einen 
Bauplan klar von der „Implementierung“ durch das fertig gestellte Gebäude zu 
trennen. Der enge Zusammenhang zwischen Spezifikation und Implementierung - 
und die sich hieraus ergebende unscharfe Trennung zwischen den Entwicklungs- 
phasen Anforderungsanalyse, Lösungsentwurf und Implementierung - ist als eine 
zentrale Besonderheit der Informationsverarbeitung bzw. der Informatik im Ver- 
gleich zu traditionellen Ingenieurwissenschaften zu betrachten. 
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Eine Funktionsspezifikation kann prinzipiell auch in natürlichsprachiger 
Form erfolgen. Beispielsweise charakterisiert der folgende Textausschnitt die 
Funktion der Kundenbedienung bei einer Autovermietung: 

„Ein Mietvorgang beginnt mit dem Check-Out, bei dem der Kun- 
de den Mietvertrag unterschreibt und dann ein Fahrzeug erhält. Ziel 
ist eine qualitativ hochwertige Bedienung von Kundenwünschen hin- 
sichtlich der Bereitstellung des gewünschten Fahrzeugtyps. Sofern ei- 
ne vorausgehende Reservierung vorliegt, . . . “ 

Diese Beschreibung ist noch relativ grob, so dass in einem nächsten Schritt 
ebenfalls noch natürlichsprachig eine detaillierte Beschreibung erfolgen könn- 
te. Auch wenn eine solche Darstellung auf den ersten Blick einfach zugäng- 
lich erscheint, können umfangreiche natürlichsprachige Beschreibungen rela- 
tiv schnell unübersichtlich und kompliziert werden und darüber hinaus auf- 
grund der fehlenden Exaktheit der Sprache verschiedene Interpretationen zu- 
lassen. 

In bestimmten Situationen kann der einer Funktion zugrunde liegende 
Sachverhalt über mathematische Modelle formal dargestellt werden. Dies be- 
zieht sich insbesondere auf quantitativ formulierbare Entscheidungsmodelle, 
bei denen in Abhängigkeit von gewissen Eingangsdaten eine Problemstellung 
über die Ermittlung einer optimalen Handlungsalternative gelöst werden soll. 
Beispielsweise kann sich die Aufgabe einer ertragsmaximierenden Zuordnung 
von Fahrzeugen zu Kunden der Autovermietung als Teilfunktion des voraus- 
gehend betrachteten Beispiels ergeben. Unter Annahme bestimmter Vereinfa- 
chungen kann dies über ein mathematisches Optimierungsmodell formuliert 
werden. Auf die mathematische Modellierung wird in Abschnitt 4.7 näher 
eingegangen. 

Zur regelorientierten Spezifikation einfach strukturierter Entscheidungs- 
funktionen können Entscheidungstabellen und Entscheidungsbäume verwen- 
det werden. In einer Entscheidungstabelle werden Bedingungen mit Entschei- 
dungen bzw. Aktionen im Sinne von Wenn-Dann-Regeln verknüpft; vgl. das 
Beispiel einer Scheckeinlösung in Abbildung 4.20. In Abbildung 4.21 erfolgt 
eine alternative Darstellung des gleichen Sachverhalts über einen Entschei- 
dungsbaum. 

Die Ablaufiogik von nicht zu komplexen Funktionen kann über Strukto- 
gramme und Programmablaufpläne in graphischer Form spezifiziert werden; 
vgl. Abbildung 4.22. Diese Darstellungsformen orientieren sich an den ty- 
pischen Konstrukten der Strukturierten Programmierung wie Sequenz (Rei- 
hung), bedingte Anweisung und bedingte Iteration (Wiederholung); vgl. Ab- 
schnitt 2.4.2. Struktogramme und Programmablaufpläne bilden häufig den 
Ausgangspunkt für eine detailliertere algorithmische Spezifikation direkt über 
programmiersprachliche Konstrukte oder einen hieran angelehnten Pseudo- 
Code. Im Rahmen der Informatik wurden außerdem verschiedene dekla- 
rative, formale Spezifikationsformen entwickelt, die allerdings für den Ge- 
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Abbildung 4.20. Entscheidungstabelle; Quelle: Balzert (2000), S. 271 
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Abbildung 4.21. Entscheidungsbaum; Quelle: Balzert (2000), S. 276 



genstandsbereich der betriebswirtschaftlichen Praxis nur sehr eingeschränkt 
zweckmäßig und kaum gebräuchlich sind. 

Da sich informationstransformierende Funktionen insbesondere über die 
Transformation von Eingangsdaten in Ausgangsdaten ergeben, stellt sich die 
entsprechende Aufgabe einer Verknüpfung von Funktionen mit Daten. Daten- 
flussdiagramme ermöglichen eine einfache Form der Integration von Daten in 
funktionsorientierte Modelle. In Form eines gerichteten Graphen werden hier- 
bei Funktionen und so genannte Datenspeicher als Knoten sowie Datenflüsse 
als Pfeile dargestellt; vgl. das vereinfachte Beispiel in Abbildung 4.23. Suk- 
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(a) Struktogramm 



(b) Programmablaufplan 



Abbildung 4.22. Struktogramm und Programmablaufplan 



zessiv verfeinerbare Datenflussdiagramme bilden einen zentralen Bestandteil 
der so genannten Strukturierten Analyse, die in der Vergangenheit eine po- 
puläre Methode der Systemanalyse darstellte; vgl. DeMarco (1979); Raasch 
(1993). 
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Abbildung 4.23. Datenflussdiagramm 
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4.4.2 Ereignisgesteuerte Prozessketten 

Die Ereignisgesteuerten Prozessketten (EPK) wurden von Keller et al. (1992) 
als eine semi-formale, graphische Technik zur Modellierung von Geschäftspro- 
zessen auf der Fachkonzeptebene konzipiert.® Auf der Grundlage des allge- 
meinen Geschäftsprozessmodells von ARIS (vgl. Abschnitt 4.1.2) erfolgt ei- 
ne Fokussierung auf die Ablauflogik, indem Prozesse als eine Abfolge von 
Funktionen und Ereignissen betrachtet werden, wobei Ereignisse Funktionen 
auslösen können und als Ergebnis von Funktionen wiederum Ereignisse ent- 
stehen. Das heißt, Ereignisse repräsentieren in der Regel je nach ihrer Rolle 
das Auslösen (z. B. „Auftrag ist zu bearbeiten“) oder den Abschluss (z.B. 
„Auftrag wurde bearbeitet“) einer Tätigkeit, während eine Funktion eine 
solche aktive Tätigkeit im Kontext des Modellierungszweckes darstellt (z. B. 
„Auftrag bearbeiten“); damit ist jeweils im Sinne der Modellklarheit auf eine 
grammatikalisch zweckmäßige Ereignis- bzw. Funktionsbenennung zu achten. 

Die graphische Symbolik der wichtigsten EPK-Modellierungskonstrukte 
ist in Abbildung 4.24 dargestellt. Darüber hinaus existieren noch Notations- 
elemente zum Verweis auf eine Fortsetzung eines Geschäftsprozessmodells 
in einem anderen Geschäftsprozessmodell (Prozessschnittstelle/-wegweiser) 
sowie auf die Detaillierung einer Funktion in einem anderen Geschäftspro- 
zessmodell (Prozessverfeinerung) . In einer erweiterten Form können Funktio- 
nen auch ein- und ausgehende Daten sowie Organisationseinheiten als Auf- 
gabenträger zugeordnet werden (erweiterte Ereignisgesteuerte Prozessketten, 
eEPK). 

In Abbildung 4.25 ist die Struktur von EPK-Modellen beispielhaft ver- 
anschaulicht. Ereignisse und Funktionen werden als Knoten eines Graphen 
betrachtet. Ablaufzusammenhänge werden über Pfeile hergestellt, wobei 
über Konnektoren Verknüpfungen im Sinne einer Prozessverzweigung oder 
-Zusammenführung hergestellt werden können. Das links dargestellte EPK- 
Modell könnte auf einer sehr groben Ebene eine erste Annäherung an die Ab- 
bildung eines Auftragsabwicklungsprozesses darstellen; dargestellt ist die ein- 
fache Abfolge von Ereignis 1 („Auftrag eingetroffen“), Funktion 1 („Auf- 
trag bearbeiten“) und Ereignis 4 („Auftrag bearbeitet“). Eine Modellver- 
feinerung könnte zu dem rechts dargestellten EPK-Modell führen, bei dem 
das Auftreten von entweder Ereignis la („Auftrag telefonisch eingetroffen“) 
oder Ereignis Ib („Auftrag per E-Mail eingetroffen“) die Funktion la 
auslöst („informationstechnische Erfassung des Auftrags“). Nach Abschluss 
der entsprechenden Verrichtung verzweigt ein nun differenzierter dargestell- 
ter Kontrollfluss in zwei parallele (nebenläufige) Prozesszweige, die über 

® Ereignisgesteuerte Prozessketten sind insbesondere im deutschsprachigen Raum 
weit verbreitet, da zum einen die Geschäftsprozesse der betriebswirtschaftlichen 
Standardsoftware SAP R/3 in Anlehnung an Ereignisgesteuerte Prozessketten 
dokumentiert sind, und zum anderen mit dem ARIS Toolset der IDS Scheer AG 
eine effektive Unterstütznng dnrch Softwarewerkzeuge zur Verfügung steht. 
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Abbildung 4.24. Grundlegende EPK-Modellierungskonstrukte 



Ereignis 2 bzw. Ereignis 3 angestoßen werden (z.B. die parallel durch- 
zuführende technische und kaufmännische Überprüfung des Auftrags). 
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Abbildung 4.25. Beispiele für EPK-Modelle 



Für Ereignisgesteuerte Prozessketten wurden verschiedene Regeln hin- 
sichtlich der Einschränkung zulässiger Modelle vorgeschlagen. So ist es ins- 
besondere üblich, Start und Ende des Kontrollflusses von EPK-Modellen über 
Ereignisse abzubilden sowie Ereignisse und Funktionen alternierend anzuord- 
nen (gegebenenfalls mit dazwischen angeordneten Konnektoren). Bezüglich 
der Verwendung von Konnektoren ist eine Einschränkung auf die Rolle einer 
binären Prozess Verzweigung oder -Zusammenführung möglich, ohne dass die 
Ausdruckskraft von EPK-Modellen hierdurch eingeschränkt würde, da sich 
komplexere Kontrollflusszusammenhänge über die Kombination entsprechen- 
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der einfacher Strukturen nachbilden lassen. Vor diesem Hintergrund ergeben 
sich die in Abbildung 4.26 dargestellten grundsätzlichen Strukturen zur Ver- 
knüpfung von Funktionen und Ereignissen (Kontrollfluss entsprechend der 
Leserichtung von oben nach unten). Die adjunktive und disjunktive Verzwei- 
gung nach einem Ereignis wird in der Regel ausgeschlossen, da eine gezielte 
Auswahl unter verschiedenen Kontrollflusszweigen nur in einer Funktion er- 
folgen kann („Ereignisse haben keine Entscheidungskompetenz“). 
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Abbildung 4.26. Zulässige Verknüpfungen in EPK-Modellen 



Generell werden Ereignisgesteuerte Prozessketten primär als semi- 
formale Modellierungstechnik eingesetzt, die es erlaubt, auf einer 
betriebswirtschaftlich-fachlichen Ebene Geschäftsprozesse in einer ersten 
Annäherung anschaulich zu modellieren; vgl. z.B. die Beispiele in Scheer 
(1997) und Stand (2001). Allerdings ist zu konstatieren, dass die fehlende 
Definition einer allgemeingültig akzeptierten formalen Syntax und verhal- 
tensbezogenen Semantik (insbesondere hinsichtlich eindeutiger Regeln für 
die Zustandsänderungen einer Prozessinstanz im Sinne eines echten dyna- 
mischen Prozessmodells) zwar die Erstellung von EPK-Modellen für den 
„Nicht-Fachmann“ auf den ersten Blick vereinfacht, allerdings die Interpre- 
tation und Nutzung entsprechender Modelle erschwert. Dies bezieht sich ins- 
besondere darauf, dass gebräuchliche Vorgehensweisen für die Erstellung von 
EPK-Modellen zu Mehrdeutigkeiten und Unklarheiten führen können, die 
es erschweren, die Konsistenz von EPK-Modellen hinsichtlich verschiedener 
Kriterien zu verifizieren und zulässige Kontrollflussabläufe zu analysieren. 
Problematisch ist beispielsweise die Semantik der adjunktiven Verknüpfung 
im Zusammenhang mit der Zusammenführung nicht klar aufeinander bezo- 
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gener Kontrollflusszweige. Dementsprechend wurden verschiedene Formali- 
sierungen der EPK-Methodik entwickelt, die teilweise auf der Definition von 
Transformationen in die im folgenden Abschnitt behandelten Petri-Netze ba- 
sieren; vgl. van der Aalst (1999), Chen und Scheer (1994), Langner et al. 
(1997), Rittgen (2000), Nüttgens und Rump (2002), van der Aalst et al. 
(2002) sowie Kindler (2004). 

4.4.3 Petri-Netze 

Petri-Netze dienen der Modellierung, Analyse und Simulation von verteil- 
ten, dynamischen Systemen mit nebenläufigen und nicht-deterministischen 
Vorgängen. Zurückgehend auf das grundlegende Konzept von Petri (1962) 
wurden diverse Petri-Netz-Varianten entwickelt, die zur prozessorientierten 
Modellierung in unterschiedlichsten Anwendungsbereichen eingesetzt werden; 
vgl. z.B. Baumgarten (1996) sowie Schnieder (1999, Kapitel 5). Wesentliche 
Vorteile von Petri-Netzen sind zum einen ihre formale mathematische Fun- 
dierung sowie zum anderen die explizite Abbildung des Prozessinstanzzu- 
standes über ein Markierungskonzept; vgl. die folgenden Abschnitte. Petri- 
Netze beinhalten über ihre verhaltensbezogene Semantik klare Regeln für 
Zustandsänderungen von Prozessinstanzen im Sinne eines echten dynami- 
schen Prozessmodells, was die Grundlage für entsprechende analytische und 
simulative Untersuchungen bildet. 

Petri-Netze basieren auf zwei grundlegenden Abstraktionsmechanismen: 
Stellen und Transitionen. Stellen repräsentieren Zustände in einem passiven 
Sinne, indem das Vorliegen gewisser Objekte, Bedingungen oder Informatio- 
nen abgebildet wird. Transitionen repräsentieren Zustandsveränderungen in 
einem aktiven Sinne, indem der Zustand involvierter Stellen verändert wird 
(etwa im Sinne eines Verbrauchs oder einer Erzeugung von Objekten). In 
der graphischen Darstellung werden Stellen als Kreise sowie Transitionen als 
Rechtecke repräsentiert. Pfeile verbinden Stellen mit Transitionen oder umge- 
kehrt. Der (lokale) Zustand einer Stelle wird über Marken (Tokens) abgebil- 
det; der (globale) Zustand eines Petri-Netzes ergibt sich damit über die kom- 
binierte Markierung aller Stellen. In Abbildung 4.27 ist ein einfaches Petri- 
Netz dargestellt (in zwei verschiedenen Zuständen). Zwei (Eingabe-)Stellen 
S\ und S 2 sind Vorgänger einer Transition T mit einer (Ausgabe-) Stelle S^. 
In dem dargestellten (Anfangs-) Zustand sind die Stellen Si und S 2 mit zwei 
bzw. einer Marke belegt. 

Die dynamische Entwicklung einer über ein markiertes Petri-Netz re- 
präsentierten Prozessinstanz erfolgt auf der Basis so genannter Schaltregeln. 
Eine Transition bewirkt eine Zustandsveränderung (sie schaltet), indem von 
allen ihren Eingabestellen jeweils eine Marke entfernt wird, und zu allen ihren 
Ausgabestellen jeweils eine Marke hinzugefügt wird. Ein Schalten der Transi- 
tion T aus Abbildung 4.27 führt damit ausgehend von dem links dargestellten 
Zustand zu dem rechts dargestellten Zustand. Vor einem möglichen Schalten 
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Abbildung 4. 27. Einfaches Petri-Netz-Beispiel 



einer Transition müssen in Abhängigkeit von der zugrunde gelegten Petri- 
Netz-Variante gewisse Vorbedingungen bezüglich der Markierung involvierter 
Stellen erfüllt sein. Sind diese Vorbedingungen für eine Transition erfüllt, so 
spricht man auch von einer aktivierten Transition. Sind gleichzeitig mehrere 
Transitionen aktiviert (d.h., es liegt ein Konflikt vor), ist die Auswahl der 
zunächst schaltenden Transition unbestimmt (und die durch das Petri-Netz 
ausgedrückte Spezifikation damit in einem gewissen Sinne unvollständig). 

Die einfachste Petri-Netz-Variante sind die Bedingungs-Ereignis-Netze. 
Hierbei repräsentieren Stellen Bedingungen, die entweder erfüllt sind oder 
nicht; dementsprechend enthält eine Stelle genau eine oder keine Marke. Die 
Schaltregel der in diesem Zusammenhang als Ereignis bezeichneten Transitio- 
nen entspricht der obigen Beschreibung. Damit ergibt sich als Vorbedingung 
für eine Aktivierung einer Transition das Vorliegen von jeweils einer Marke 
in allen Eingabestellen der Transition sowie ein Fehlen einer Marke in allen 
Ausgabestellen. In Abbildung 4.28 ist als ein klassisches Beispiel die Syn- 
chronisation von zwei Robotern, die auf gegenüberliegenden Montageplätzen 
Leiterplatten bestücken, die auf einem gemeinsam genutzten Fließband ange- 
liefert werden, als ein Bedingungs-Ereignis-Netz dargestellt; vgl. z. B. Balzert 
(2000) oder Schnieder (1999). Bei dem gezeigten Anfangszustand sind beide 
Transitionen, die das Ergreifen von angelieferten Leiterplatten repräsentieren, 
aktiviert. Aufgrund des vorliegenden Konflikts kann nur eine dieser beiden 
Transitionen schalten, was zu einer Bestückung durch den entsprechenden 
Roboter führt, der damit zunächst keine weiteren angelieferten Leiterplatten 
übernehmen kann. Das dargestellte Bedingungs-Ereignis-Netz stellt damit 
sicher, dass die Vorgangsabwicklung in dem modellierten Fertigungssystem 
entsprechend technolgischer Reihenfolgebedingungen abläuft. 

Als Verallgemeinerung von Bedingungs-Ereignis-Netzen kann ein Stellen- 
Transitions-Netz prinzipiell beliebig viele Marken je Stelle aufnehmen. Dabei 
kann die Kapazität von Stellen individuell nach oben beschränkt werden (in 
der graphischen Darstellung über das Hinzufügen von „k = . . an der je- 
weiligen Stelle). Außerdem können Kantengewichte definiert werden (in der 
graphischen Darstellung über das Hinzufügen einer positiven ganzen Zahl 
an der jeweiligen Kante bzw. dem jeweiligen Pfeil), die angeben, wie viele 
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Abbildung 4.28. Petri-Netz für die Leiterplattenbestückung durch zwei Roboter 



Marken einer Stelle entnommen oder hinzugefügt werden, wenn die entspre- 
chende nach- bzw. vorgelagerte Transition schaltet (im Zusammenhang mit 
einer analogen Aktivierungsregel). 

Im Hinblick auf die Abbildung elementarer Zusammenhänge sind in Ab- 
bildung 4.29 die grundsätzlichen Strukturelemente von Petri-Netzen auf- 
geführt; vgl. Balzert (2000). Über zweckmäßige Kombinationen dieser Ele- 
mente können komplexere Strukturen gebildet werden; vgl. die einfachen 
Muster in Abbildung 4.30. 

Struktur und Verhalten von Petri-Netzen können in algebraischer Form 
formal definiert werden; vgl. z. B. Baumgarten (1996). Auf dieser Basis sind 
in Abhängigkeit von der Petri-Netz- Variante verschiedene Analysemethoden 
entwickelt worden, mit denen ausgehend von einem Anfangszustand beispiels- 
weise untersucht werden kann, 

• welche Folgezustände erreicht werden können (Erreichbarkeit), 

• ob eine kritische Markenzahl für eine bestimmte Stelle in einem Prozessab- 
lauf nicht überschritten werden kann (Sicherheit), 

• ob für jede Transition gilt, dass von jedem erreichbaren Zustand ein Zu- 
stand erreicht werden kann, in dem die Transition aktiviert ist (Lebendig- 
keit) 

• ob jeder erreichbare Zustand mindestens eine aktivierte Transition besitzt 
(Verklemmungsfreiheit, schwache Lebendigkeit). 

Die Überprüfung eines Petri-Netzes hinsichtlich solcher Kriterien kann ins- 
besondere dazu beitragen, mögliche Modellierungsfehler aufzudecken. 
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Abbildung 4.29. Elementare Strukturelemente von Petri-Netzen 
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Abbildung 4.30. Typische Muster in Petri-Netzen 



Neben den oben dargestellten Petri-Netz-Grundformen existieren ver- 
schiedene erweiterte Petri-Netze- Varianten; vgl. z.B. Baumgarten (1996) so- 
wie Schnieder (1999, Kapitel 5). 

• Prädikat- Transitions- Netze bzw. Petri-Netze mit individuellen Marken 
ermöglichen die direkte Abbildung komplexer Zustände über ein flexibleres 
Markierungskonzept, was im Zusammenhang mit erweiterten Schaltregeln 
steht. Gegebenenfalls können hierbei auch nicht diskrete Zustände bzw. 
Zustandsveränderungen abgebildet werden. 
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• Hierarchische Petri-Netze ermöglichen die Verfeinerung von Teilprozessen 
in separaten Petri-Netzen, was entsprechende Regeln zur Konsistenzerhal- 
tung („komplementäre Schnittstellen“) voraussetzt. Auf einer groben Ebe- 
ne können hierbei Kanal-Instanzen-Netze, bei denen die Systemdynamik 
noch nicht formal spezifiziert ist, den Ausgangspunkt bilden. 

• Zeitbehaftete Petri-Netze ermöglichen die Abbildung von Zeitpunkten und 
-dauern, wodurch etwa die Reihenfolge des Schaltens sowie des Markenver- 
brauchs gesteuert werden kann. 

• In stochastischen Petri-Netzen können auch nicht-deterministische 
Zustände bzw. Zustandsveränderungen explizit abgebildet werden. 

Solche Erweiterungen unterstützen eine problemadäquate, kompakte Model- 
lierung in verschiedenen Anwendungsbereichen. Allerdings sind Petri-Netze 
trotz ihrer Ausdruckskraft, mathematischen Fundierung, graphischen Veran- 
schaulichung von Prozessstruktur und -dynamik und weitreichenden Analy- 
sierbarkeit für die Geschäftsprozessmodellierung in der Praxis nur mäßig ver- 
breitet. Dies kann zumindest teilweise auf ihren hohen Abstraktionsgrad im 
Sinne von geschäftsprozessunspezifischen Modellierungskonstrukten zurück- 
geführt werden. 



4.5 Objektorientierte Modellierung 

Objektorientierung ist ein grundlegender Ansatz zur Systemmodellierung und 
-gestaltung, der heute in umfassendem Maße verwendet wird. Das wesentliche 
Prinzip besteht darin, dass bei der Modellierung bzw. der Systemarchitektur 
Objekte die Basiskonstrukte bilden. Unter einem Objekt versteht man einen 
identifizierbaren Gegenstand der Erkenntnis und Wahrnehmung, des Denkens 
und Handelns. Objekte stellen eine Einheit dar, sind gegebenenfalls über Be- 
ziehungen verbunden und nach außen über Operationen bzw. entsprechendes 
Verhalten sichtbar. 

Das wesentliche Konzept der Objektorientierung ist die Zusammenfas- 
sung bezüglich Struktur und Verhalten gleichartiger Objekte bzw. entspre- 
chender Abstraktionen des Anwendungsbereiches durch Klassen. Eine Klasse 
kann man folglich auch als einen (Objekt-)Typ oder eine Kategorie bezeich- 
nen. Ein Objekt einer Klasse wird auch als Exemplar (oder, als sprachlich 
unglückliche Übersetzung des englischen Begriffes Instance, „Instanz“) dieser 
Klasse bezeichnet. In diesem Sinne können Klassen als Erweiterung der in 
Abschnitt 4.2.1 betrachteten Entity-Typen um den Verhaltensaspekt angese- 
hen werden. 

Der objektorientierte Ansatz kann relativ durchgängig in verschiedenen 
Phasen der Systementwicklung angewendet werden. Typischerweise unter- 
scheidet man hier in 

1. objektorientierte Analyse (die Entwicklung eines entsprechenden fachli- 
chen Modells des Anwendungsbereiches), 
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2. objektorientierten Entwurf (die Umsetzung dieses Modells in eine Sys- 
temarchitektur, die das grundsätzliche Zusammenwirken von Komponen- 
ten bestimmt) sowie 

3. objektorientierte Implementierung (Programmierung). 

Aus dem Blickwinkel der Softwareentwicklung kann die objektorientier- 
te Methode als evolutionäre Weiterentwicklung des Konzeptes des abstrakten 
Datentyps aufgefasst werden. Unter einem abstrakten Datentyp versteht man 
eine formale Beschreibung einer Menge gleichartiger Objekte über die Spezifi- 
kation der auf solche Objekte anwendbaren Methoden; vgl. z. B. Meyer (1997, 
Kapitel 6). Hierauf aufbauend strukturiert eine Klasse gleichartige Objekte 
mittels Eigenschaften (mit Wertebereichen) und Methoden (Operationen). 
Ein Objekt ist charakterisiert durch 

• seine Identität, 

• seine durch seine Klasse strukturierten Eigenschaften (d. h. einen Zustand, 
der sich ändern kann) sowie 

• ein von seinem aktuellen Zustand abhängiges Verhalten, was sich über 
entsprechende Methoden der Klasse ergibt. 

Dabei kapselt eine Klasse interne Details wie die Datenstruktur und die Im- 
plementierung des Verhaltens. Die Funktionalität einer Klasse kann dann nur 
über eine spezifizierte Schnittstelle genutzt werden. Dieses Verbergen von für 
den Nutzer nicht relevanten Realisierungsdetails bezeichnet man als das Prin- 
zip des Information Hidiny, vgl. Parnas (1972a, b). 

Im Rahmen der objektorientierten Modellierung werden verschiedene As- 
pekte bzw. Sichten in verschiedenen Phasen der Systementwicklung betrach- 
tet. Hier kann vereinfachend in die Abbildung statisch-struktureller sowie 
dynamisch-verhaltensbezogener Zusammenhänge unterschieden werden, die 
in den beiden folgenden Abschnitten kurz betrachtet werden. Hierbei legen 
wir die Unified Modeling Language (UML) zugrunde. Die UML ist eine ob- 
jektorientierte, graphische Beschreibungssprache zur Visualisierung, Spezifi- 
kation, Konstruktion und Dokumentation der Artefakte von primär aus Soft- 
ware bestehenden Systemen; vgl. Booch et al. (2005). Das heißt, die UML 
kann in verschiedenen Betrachtungsebenen der Modellierung und Phasen 
der Softwareentwicklung eingesetzt werden. Die UML hat sich als Standard- 
modellierungssprache der OMG {Object Management Group) in der Praxis 
durchgesetzt und wird inzwischen verbreitet von GASE- Tools (GASE: Com- 
puter Aided Software Engineering) unterstützt. Zur weiteren Vertiefung in die 
objektorientierte Modellierung auf Basis der UML sei z.B. auf Booch et al. 
(2005), Balzert (2004), Jacobson et al. (1999) sowie Fowler (2004) verwiesen. 

4.5.1 Statisch-strukturelle Modelle 

Uber statisch-strukturelle Modelle werden insbesondere Gemeinsamkeiten, 
Unterschiede und Beziehungen zwischen Klassen bzw. Objekten abgebildet. 
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Es ist offensichtlich, dass es Objekte gibt, die wesentliche Gemeinsamkei- 
ten besitzen, sich aber andererseits in gewissen Aspekten unterscheiden. Das 
heißt, solche Objekte haben einen gleichartigen, nicht aber einen identischen 
Typ. Folglich ist es zweckmäßig, für eine Menge von Objekten eine Gemein- 
samkeit wesentlicher Gharakteristika bei einer Variabilität spezieller Gha- 
rakteristika abbilden zu können. Hierfür wurde das Konzept der Vererbung 
entwickelt. Die grundlegende Idee der Vererbung besteht darin, Gemeinsam- 
keiten in einer entsprechend allgemeinen (Ober-)Klasse sowie differierende 
Gharakteristika mittels spezialisierender (Unter-) Klassen abzubilden. Dabei 
erbt die spezialisierende (abgeleitete) Klasse die Eigenschaften und Methoden 
der allgemeinen Klasse und besitzt damit automatisch auch deren Eigen- 
schaften und Methoden. Die Beziehung zwischen allgemeinen Klassen und 
spezialisierenden Klassen bezeichnet man auch als Spezialisierung bzw. Ge- 
neralisierung. 

Zur Veranschaulichung des Klassen- und Vererbungskonzeptes greifen wir 
das im ersten Kapitel kurz charakterisierte Anwendungsbeispiel des Gon- 
tainerterminals wieder auf. Ziel sei die Abbildung eines solchen Gontainer- 
terminals über ein objektorientiertes Modell, welches als Grundlage für ein 
Simulationsmodell (vgl. Abschnitt 4.6) sowie ein Ablaufdispositionssystem 
dienen soll. Hier betrachten wir beispielhaft die Abbildung von so genann- 
ten Gontainerumschlaggeräten, die zum Transport von Gontainern auf dem 
Gontainerterminal bzw. vom und zum Schiff dienen. Vereinfachend nehmen 
wir an, dass lediglich zwei verschiedene Geräte zum Einsatz kommen: ho- 
rizontal zur Kaimauer bewegliche Verladebrücken (zum Transport aus dem 
Schiff auf einen Pufferlagerplatz unter der Verladebrücke und umgekehrt) 
und frei auf dem Yard bewegliche Portalhubfahrzeuge (zum Transport der 
Gontainer vom Gontainerterminal zum Pufferlagerplatz einer Verladebrücke 
und umgekehrt). 

In Abbildung 4.31 ist ein so genanntes Klassendiagramm für Gontainer- 
umschlaggeräte dargestellt. Klassen werden über Rechtecke dargestellt, die in 
verschiedene Bereiche untergliedert werden können (typischerweise: Bezeich- 
nung, Eigenschaften, Methoden). Die Gemeinsamkeiten von Verladebrücken 
und Portalhubfahrzeugen sind in einer abstrakten Klasse zusammengefasst. 
Dies betrifft die gemeinsame Eigenschaft Inventarnummer sowie zwei Metho- 
den zum Aktivieren bzw. Deaktivieren eines Gerätes. Andererseits ergeben 
sich Unterschiede; beispielsweise könnte für eine Verladebrücke der Maximal- 
durchsatz (bewertet in Anzahl Gontainer pro Stunde) relevant sein, während 
für ein Portalhubfahrzeug die maximale Fahrgeschwindigkeit und die ma- 
ximale Hubhöhe wichtige Attribute darstellen. Die Tätigkeiten einer Verla- 
debrücke erstrecken sich auf das Laden oder Entladen eines Gontainers auf 
das Schiff bzw. vom Schiff. Ein Portalhubfahrzeug transportiert jeweils einen 
Gontainer von einer Position zu einer anderen Position auf dem Yard. 

Klassendiagramme können damit über die Klassenbildung und den Ver- 
erbungsmechanismus Gemeinsamkeiten und Unterschiede von Objekten bzw. 
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Abbildung 4.31. Beispiel für ein Klassendiagramm mit Vererbungsbeziehungen 



Objekttypen strukturieren. Eine Abbildung der Konzepte eines Anwendungs- 
bereiches über entsprechende Klassenhierarchien ermöglicht eine strukturier- 
te (modellbasierte) Form der Wiederverwendung über eine Erweiterung und 
Anpassung entsprechender Klassen. Dieser Aspekt wird in Abschnitt 6.4.1 
näher erläutert. 

In Klassendiagrammen können neben Vererbungsbeziehungen auch 
vielfältige andere Beziehungen abgebildet werden. So können ähnlich wie in 
Entity-Relationship-Modellen (vgl. Abschnitt 4.2.1) über so genannte Asso- 
ziationen mögliche Beziehungen zwischen Objekten bestimmter Klassen ab- 
gebildet werden. Zur Veranschaulichung der Notation ist in Abbildung 4.32 
der Gegenstandsausschnitt aus Abbildung 4.6 (S. 107) dargestellt. Die in dem 
Beispiel mit der Assoziation verknüpfte anonyme Klasse ist nur erforderlich, 
da es sich um einen attributierten Beziehungstyp handelt. 




Abbildung 4.32. Beispiel für ein Klassendiagramm zur Abbildung eines Daten- 
modells 
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Neben Klassendiagrammen besitzt die UML weitere Diagrammtypen zur 
Modellierung statisch-struktureller Zusammenhänge. In Objektdiagrammen 
werden auf Ausprägungsebene Objekte abgebildet und miteinander in Bezie- 
hung gesetzt; Objekte werden als Rechtecke dargestellt, wobei zur Unterschei- 
dung von Klassen die Bezeichnung unterstrichen wird. Komponentendiagram- 
me bilden die Architektur von Softwaresystemen auf der Implementierungs- 
ebene ab, wobei Komponenten implementierungstechnisch zusammengefasste 
Softwaremodule darstellen. So können beispielsweise Abhängigkeiten bzw. 
Schnittstellen zwischen verschiedenen Komponenten veranschaulicht werden. 
Verteilungsdiagramme dienen der Darstellung der Architektur von Software- 
systemen in einem verteilten Rechnersystem. 

4.5.2 Dynamisch-verhaltensbezogene Modelle 

Die UML umfasst verschiedene Diagrammtypen für die Modellierung 
dynamisch-verhaltensbezogener Aspekte. Dementsprechend überdeckt sich 
der Anwendungsbereich stark mit einigen der in Abschnitt 4.4 beschriebe- 
nen Modellierungsmethoden. 

Anwendungsfalldiagramme {Use-Case- Diagramme) dienen der Grobbe- 
schreibung typischer Szenarien der Interaktion von Aktoren (Organisations- 
einheiten) mit Systemelementen (Funktionen) im Rahmen so genannter An- 
wendungsfälle {Use Cases). Entsprechende Darstellungen (vgl. das einfache 
Beispiel in Abbildung 4.33), die in natürlichsprachiger Form ergänzt werden 
können, bilden damit einen möglichen Ausgangspunkt für eine nachfolgende 
genauere Funktions- und Prozessbeschreibung mittels weiter gehender Mo- 
dellierungstechniken . 




Versandmitarbeiter 



Abbildung 4.33. Beispiel für ein Anwendungsfalldiagramm 



Zustandsdiagramme dienen der Beschreibung möglicher System- oder Ob- 
jektzustände in der dynamischen Entwicklung. Die UML stützt sich hierbei 
im Wesentlichen auf die so genannten Statecharts von Harel (1987). In Ab- 
bildung 4.34 ist als Beispiel für ein einfaches Zustandsdiagramm der Objekt- 
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lebenszyklus eines Buches veranschaulicht. In abgerundeten Rechtecken sind 
die möglichen Zustände dargestellt. Anfangs- und Endzustand sind durch 
einen ausgefüllten bzw. einen halb ausgefüllten Kreis spezifiziert. Mögliche 
Zustandsübergänge ergeben sich über Pfeile, die über Angaben der Form 
Ereignis [Bedingung] / Aktion näher beschrieben sind. Beispielsweise 
führt für ein präsentes Buch das Ereignis eines Ausleihwunsches ohne wei- 
tere Bedingung zum Aufruf der entsprechenden Methode ausleihenO und 
einem Übergang in den Zustand ausgeliehen. Zustandsdiagramme können 
hierarchisch gegliedert werden und auch nebenläufige Zustände abbilden. 



neues Buch 




/ benachrichtigenO 

Abbildung 4.34. Beispiel für ein Zustandsdiagramm 



Aktivitätsdiagramme können als Speziallfall von Zustandsdiagrammen 
angesehen werden. Die abgebildeten Zustände (Aktivitäten im Sinne von 
„Aktions-Zuständen“) stellen hier Zwischenschritte eines algorithmischen Ab- 
laufs oder Geschäftsprozesses dar. Dementsprechend ergibt sich eine teilweise 
Überdeckung zu dem Anwendungsbereich von Ereignisgesteuertern Prozess- 
ketten und Petri-Netzen; vgl. Abschnitt 4.4. Abbildung 4.35 zeigt ein Beispiel 
für ein Aktivitätsdiagramm, bei dem verschiedene Verzweigungsformen dar- 
gestellt sind. 

Im Rahmen des Anwendungssystementwicklungsprozesses können Akti- 
vitätsdiagramme den Ausgangspunkt für implementierungsnähere Modelle 
bilden, in denen die Interaktion zwischen Objekten abgebildet wird (d. h. 
mögliche Abfolgen des Nachrichtenaustausches bzw. Methodenaufrufes). In 
Abhängigkeit von der Darstellungsform unterscheidet man entsprechende In- 
teraktionsdiagramme in Sequenz- und Kollaborationsdiagramme; vgl. Abbil- 
dung 4.36. Bei Sequenzdiagrammen steht der Kontrollfluss im zeitlichen Ab- 
lauf im Mittelpunkt, während Kollahorationsdiagramme eher die strukturel- 
len Beziehungen zwischen Objekten im Interaktionszusammenhang hervor- 
heben. 
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Abbildung 4.35. Beispiel für ein Aktivitätsdiagramm 



Sequenzdiagramm: 




Kollaborationsdiagramm: 




Abbildung 4.36. Beispiel für Interaktionsdiagramme 



4.6 Simulation 

Gemäß der VDI-Richtlinie 3633 ist Simulation das Nachbilden eines dyna- 
mischen Prozesses in einem System mit Hilfe eines experimentierfähigen Mo- 
dells, um zu Erkenntnissen zu gelangen, die auf die Wirklichkeit übertragbar 
sind. Eine Simulation wird oftmals dann durchgeführt, wenn Experimente am 
realen System zu aufwändig, zu teuer, zu gefährlich, nicht replizierbar oder 
nicht durchführbar sind und andererseits eine geschlossene mathematische 
Formulierung und analytische Lösung eines Problems nicht möglich ist. 
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Allgemeine Beispiele für Anwendungen der Simulation sind Flugsimula- 
tionen für Flugschüler, Crashtests, die Berechnung der Folgen globaler Klima- 
veränderungen oder die dynamische Darstellung der Entwicklung einer Volks- 
wirtschaft. Im Rahmen der betrieblichen Planung ergeben sich insbesondere 
Einsatzmöglichkeiten der Simulation zur explorativen Bewertung verschiede- 
ner Szenarien. Ein Beispiel ist die Dimensionierung von Fertigungssystemen, 
deren Leistungsfähigkeit in verschiedenen Ausgestaltungsformen mittels Si- 
mulation abgeschätzt werden kann. 

Der grundlegende Ablauf beim Simulieren kann folgendermaßen darge- 
stellt werden:® 

1. Erstellung einer Simulationsmodellbeschreibung und Datenerhebung 

2. Implementierung und Validierung des Simulationsmodells 

3. Iterative Durchführung und Auswertung von Experimenten 

4. Übertragung der Ergebnisse auf die Realität 

Im Kontext der Betriebswirtschaftslehre (insbesondere in den Bereichen 
Produktion und Logistik) wird in der Regel die diskrete, ereignisorientierte 
Simulation verwendet. Das heißt, es werden diskrete Zeitpunkte betrachtet, 
zu denen Ereignisse auftreten. Diese Ereignisse werden chronologisch abgear- 
beitet, wobei jeweils Zustandsübergänge oder -änderungen über Änderungen 
von Modellvariablen abgebildet werden. Dabei ziehen Ereignisse häufig Fol- 
geereignisse nach sich. Ereignisse werden, geordnet nach dem Zeitpunkt, zu 
dem sie stattfinden, in einer so genannten Ereignisliste {Ereigniskalender) 
verwaltet. Der grundlegende Ablauf bei der Ausführung eines entsprechen- 
den Simulationslaufes ergibt sich folgendermaßen: 

1. Initialisiere die Ereignisliste chronologisch mit den Startereignissen. 

2. Solange das Simulationsende nicht erreicht ist, wiederhole: 

a) Hole das nächste Ereignis E aus der Ereignisliste und setze den ak- 
tuellen Simulationszeitpunkt entsprechend; 

b) arbeite das Ereignis E ab; 

c) füge die Folgeereignisse chronologisch sortiert zur Ereignisliste hinzu. 

Prinzipiell könnte man einen Simulationslauf manuell durchspielen. Nor- 
malerweise verwendet man hierzu aber Simulationssysteme {Simulatoren), 
die die Erstellung von Simulationsmodellen und das Durchführen entspre- 
chender Simulationsläufe unter Berücksichtigung komplexer dynamischer 
Abläufe und eines stochastischen Systemverhaltens erst effektiv ermögli- 
chen.^® Hierzu bieten Simulatoren in der Regel verschiedene vordefinierte 
Komponenten, die z. B. für die Abbildung von Fertigungssystemen verwendet 

® Als weiterführende Literatur zur Simulation vgl. z.B. Kostouriak und Gregor 
(1995) sowie Law und Kelton (2000). 

Die theoretische Grundlage entsprechender Simulationsmodelle bilden insbeson- 
dere die in Abschnitt 4.4.3 betrachteten Petri-Netze (in einer zeitbehafteten, 
stochastischen Variante mit individuellen Marken). 
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werden können (Maschinen, Puffer, Förderbänder, Fahrzeuge, Paletten usw.). 
Moderne Simulationssysteme sind häufig objektorientiert gestaltet und erlau- 
ben dann in Verbindung mit einer integrierten Programmiersprache die Er- 
weiterung und Anpassung solcher Komponenten. Zur Veranschaulichung der 
Simulation bieten Simulationssysteme typischerweise eine graphische Benut- 
zeroberfläche, die sowohl die Erstellung von Simulationsmodellen unterstützt 
als auch die Visualisierung von Simulationsläufen ermöglicht. 

Im Folgenden soll das Vorgehen bei einer Simulation am Beispiel der 
Gestaltung einer Tankstelle erläutert werden. Diese soll aus einer Kombi- 
zapfsäule für Normal- und Superbenzin und einer Superzapfsäule nur für 
Superbenzin bestehen. Erfahrungsgemäß benötigen Kunden 3,5 Minuten pro 
Tankvorgang bei Superbenzin und 3 Minuten pro Tankvorgang bei Normal- 
benzin. Weiterhin sind Erwartungswerte für Eintreffzeitpunkte von Kunden 
gegeben. Ziel der Simulation ist die Überprüfung der anforderungsgerechten 
Dimensionierung der Tankstelle sowie gegebenenfalls das Aufzeigen verbes- 
serter Gestaltungsoptionen. 

Der erste Schritt besteht in der Modellierung des Problems unter Berück- 
sichtigung der Modellgrenzen des abzubildenden Wirklichkeitsausschnittes 
(Systemgrenzen). Es müssen die unbeweglichen und beweglichen Objekte, 
die möglichen Zustände sowie Entscheidungsregeln bestimmt werden. Unbe- 
wegliche Objekte sind in unserem Beispiel die Kombizapfsäule K, die Super- 
zapfsäule S, die Warteschlange vor der Kombizapfsäule WK und die Warte- 
schlange vor der Superzapfsäule WS. Bewegliche Objekte sind nur die Kun- 
den (bzw. deren Kraftfahrzeuge). Mögliche Zustände betreffen die Zapfsäulen 
(frei oder belegt), die Warteschlangen (frei oder belegt; wenn belegt, dann 
die Länge der Warteschlange) und die Kraftfahrzeuge (wartend oder in Be- 
dienung) . 

Entscheidungen müssen dahingehend getroffen werden, an welcher Zapf- 
säule sich ein Kunde (bzw. Kraftfahrzeug) zum Tanken anstellt. Kunden für 
Normalbenzin haben aufgrund der Konzeption der Tankstelle keine Wahl 
und reihen sich in die Warteschlange WK ein. Für Kunden von Superbenzin 
dagegen werden folgende Regeln aufgestellt: 

1. Sind beide Zapfsäulen frei, so belege S. 

2. Ist nur eine Zapfsäule frei, so belege die freie Säule. 

3. Ist keine Zapfsäule frei, so wähle die kürzere Warteschlange. 

Im zweiten Schritt erfolgt die Umsetzung des Modells in ein Simulations- 
system. Die Entscheidungsregeln werden hierbei in der Regel mittels einer 
in das Simulationssystem integrierten Simulationssprache programmiert. Die 
Eingangsdaten (z.B. die Ankunftszeitpunkte von Kunden) können über Ta- 
bellen zur Verfügung gestellt oder auf der Basis von Wahrscheinlichkeitsver- 
teilungen erzeugt werden. 

Im dritten Schritt erfolgt die Ausführung und Auswertung von Simula- 
tionsexperimenten. In diesem Beispiel kann die Durchführung von Simulati- 
onsläufen gegebenenfalls auch manuell erfolgen, während umfassende Simu- 
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lationsexperimente normalerweise per Rechner erfolgen. Moderne Simulati- 
onssysteme ermöglichen meist eine graphische Visualisierung des Prozessab- 
laufes, die es u. a. erlaubt, das Experiment in Realzeit, zeitlich gerafft oder 
verzögert zu verfolgen. 

Als Ergebnisgrößen der Simulationsexperimente sind hier etwa die Kun- 
denwartezeiten (Maximum, Minimum und Durchschnitt), die Warteschlan- 
genlängen (Maximum, Minimum und Durchschnitt) und die Auslastung der 
Zapfsäulen relevant. 

Tabelle 4.1 stellt ein Beispiel für den konkreten Ablauf einer manuellen 
Simulation der Tankstelle dar, wobei die Eintreffzeitpunkte fest vorgegeben 
seien. Jedes Ereignis (d.h. Eintreffen oder Wegfahren eines Kunden) wird in 
einer Zeile der Tabelle dargestellt. Die Ereignisliste enthält jeweils alle Er- 
eignisse (mit Zeitpunkt des Eintreffens des Ereignisses, Ereignistyp und einer 
Nummer zur Identifikation), die zu einem Zeitpunkt bekannt und noch nicht 
abgearbeitet sind. Die 5. Zeile gehört zum Ereignis „Weggang des Kunden 1 
von der Superzapfsäule S zum Zeitpunkt 4,5“. Dadurch ist der Zustand der 
Zapfsäule S und die Ereignisliste gegenüber der vorigen Zeile verändert. Zum 
gleichen Zeitpunkt tritt auch das Ereignis „Weggang des Kunden 2 von der 
Kombizapfsäule K“ ein. Somit hat Kunde 3 die Möglichkeit, von der War- 
teschlange WK zur Zapfsäule K zu wechseln, wodurch der Zustand von K 
gegenüber der vorigen Zeile unverändert ist, die Warteschlange WK jedoch 
leer wird. Gleichzeitig ist dadurch in die Ereignisliste ein weiteres Ereignis 
aufgenommen worden, nämlich der Weggang von Kunde 3 von der soeben 
betretenen Zapfsäule K. 



Zeit t 


S K WS WK 


Ereignisliste {t; Typ; Nr.) 


0 


leer leer leer leer 


(1; Zugang Superbenzin; 1) 


1 


belegt leer leer leer 


(1,5; Zugang Normalbenzin; 2) 
(4,5; Anstritt S"; 1) 


1,5 


belegt belegt leer leer 


(4; Zugang Normalbenzin; 3) 
(4,5; Anstritt S"; 1) 

(4,5; Anstritt A; 2) 


4 


belegt belegt leer < 3 ] 


(4,5; Anstritt S"; 1) 

(4,5; Anstritt K\ 2) 

(6,5; Zugang Snperbenzin; 4) 


4,5 


leer belegt leer < 3 ] 


(4,5; Anstritt A; 2) 

(6,5; Zugang Snperbenzin; 4) 


4,5 


leer belegt leer leer 


(6,5; Zugang Snperbenzin; 4) 
(7,5; Anstritt A; 3) 









Tabelle 4.1. Simulation einer Tankstelle 





4.6 Simulation 
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Aus einer derartigen Simulation kann man beispielsweise schließen, dass 
die Zapfsäule K zu 90%, die Zapfsäule S zu 70% ausgelastet ist und dass 
nur die Warteschlange WK für 10% der Zeit mit einem Fahrzeug belegt ist, 
so dass Kunden für Normalbenzin durchschnittlich eine halbe Minute warten 
müssen. 

Vor einer Übertragung der Ergebnisse auf die Realität sollte nochmals 
rückblickend überprüft werden, ob die Prämissen korrekt und praxisnah und 
die zu Grunde gelegten Eingabedaten realistisch sind. Dies betrifft in unse- 
rem Beispiel insbesondere die angenommenen Ankunftszeiten. Ein weiterer 
Kritikpunkt könnte die deterministische Zapfstellenauswahl der Kunden für 
Superbenzin sein. Ebenso erscheint ein Weiterfahren von Kunden bei langer 
Schlange realistisch, wurde jedoch nicht berücksichtigt. Mögliche Modellmo- 
difikationen könnten daher einerseits die Einführung stochastischer Ankunfts- 
zeiten (z. B. negativexponential verteilte Zwischenankunftszeiten von durch- 
schnittlich zwei Minuten bei einer Wahrscheinlichkeit von 60% für Kunden 
von Superbenzin) sein, andererseits könnte die erste Entscheidungsregel für 
Superbenzinkunden dahingehend geändert werden, dass sie zufällig aus den 
beiden Zapfsäulen auswählen, wenn beide frei sind. 

In dem diskutierten Beispiel ist eine Simulation relativ einfach durchführ- 
bar, da die Freiheitsgrade der Systemkonfiguration (wie z. B. Layout, Geräte- 
auslegung und -anzahl) vergleichsweise gering sind. Dagegen stellt sich in 
komplexeren Systemen darüber hinaus typischerweise ein simultan zu lösen- 
des Problem der Ermittlung zweckmäßiger Dispositions- bzw. Steuerungs- 
strategien. Dies kann an dem Beispiel des Gontainerterminals verdeutlicht 
werden. In Abbildung 4.37 ist ein solches Terminal ausschnittsweise darge- 
stellt. 

Ein mögliches Ziel bei der Neugestaltung eines Gontainerterminals könn- 
te darin bestehen, die Anlage so auszulegen, dass ein Gontainerschiff in 
einer vorgegebenen Höchstzeit ent- bzw. beladen werden kann, wobei die 
Investitions- und Betriebskosten des Terminals zu minimieren sind. In die- 
sem Zusammenhang sind eine Vielzahl interdependenter Entscheidungen zu 
treffen; typische Entscheidungsfelder sind im Folgenden genannt: 

• Statische Systemstruktur 

— Layout des Gontainerterminals 

— Art und Anzahl der Verladebrücken und Portalhubfahrzeuge 

• Dynamische Steuerungsstrategien 

— Zuordnung von Gontainern zu Stellplätzen auf dem Yard (und gegebe- 
nenfalls auch auf dem Schiff) 

— Zuweisung von Transportaufträgen an die Portalhubfahrzeuge und Fest- 
legung der jeweiligen Fahrwege 

Dabei ist zu beachten, dass zur Bewertung eines dynamischen Systems, welches 
über Wahrscheinlichkeitsverteilungen modelliert wird, eine hinreichende Anzahl 
von Simulationsläufen durchzuführen ist, um eine bestimmte statistische Sicher- 
heit über die erzielten Ergebnisse zu erlangen. 
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Abbildung 4.37. Containerterminal 



Für eine solche Problemstellung ist in der Regel keine optimale Lösung 
analytisch ableitbar, sondern es sind schrittweise verbesserte Gestaltungsal- 
ternativen zu entwickeln. Zweckmäßigerweise findet hierzu auf der Grundlage 
logischer Vorüberlegungen zunächst eine Eingrenzung der betrachteten Alter- 
nativen statt. Hieraufhin können auf Basis (gegebenenfalls noch relativ gro- 
ber) Simulationsmodelle mögliche Engpässe identifiziert werden. Mit einem 
damit gewonnenen Verständnis zum Systemverhalten können gegebenenfalls 
mittels verbesserter Dispositions- bzw. Steuerungsstrategien schrittweise bes- 
sere Systemkonfigurationen ermittelt werden. Die hierbei konzipierten Stra- 
tegien können den Kern eines zu entwickelnden realen Ablaufdispositionssy- 
stems bilden. 



4.7 Mathematische Modellierung 

In mathematischen Modellen werden Sachverhalte mit mathematischen Mit- 
teln (Formeln) dargestellt. Innerhalb der Unternehmensmodellierung sind ins- 
besondere Optimierungsmodelle von Interesse, da mit ihnen eine quantitative 
Darstellung von Optimierungsproblemen möglich ist. Ziel der Lösung sol- 
cher Optimierungsprobleme ist die Entscheidungsunterstützung über die Er- 
mittlung einer möglichst guten, im Idealfall optimalen Handlungsmöglichkeit 
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(z. B. die Entscheidung über Produktionsmengen im Rahmen der Produkti- 
onsplanung); vgl. z.B. Williams (2000). 

Ein Optimierungsmodell enthält eine Menge von Handlungsalternativen, 
eine diese Alternativen bewertende Zielfunktion sowie eine Angabe darüber, 
ob die Alternative mit dem kleinsten oder diejenige mit dem größten Ziel- 
funktionswert die beste, d.h. optimale Alternative ist (Minimierung bzw. 
Maximierung) . Bei der entsprechenden Erstellung von Optimierungsmodellen 
werden typischerweise mehr oder weniger starke Vereinfachungen vorgenom- 
men. So wird normalerweise angenommen, dass alle Alternativen und ihre 
Auswirkungen vollständig bekannt und quantifizierbar sind und die Präfe- 
renzen des Entscheidungsträgers über eine skalare Zielfunktion abgebildet 
werden können. Darüber hinaus wird z. B. häufig dahingehend abstrahiert, 
dass die verschiedenen Zusammenhänge mittels linearer Funktionen darge- 
stellt werden, da die daraus resultierenden linearen Optimierungsprobleme 
bei der Einschränkung auf kontinuierliche Entscheidungsvariablen effizient 
exakt gelöst werden können; vgl. Abschnitt 2.1.2. 

Ein (mathematisches) Modell eines linearen Optimierungsproblems 
(LOP) sieht in der Regel wie folgt aus: 

Maximierung (oder Minimierung) einer linearen Zielfunktion 

71 

E(x) = ^ Cj ■ Xj {= Ci ■ Xi + C 2 ■ X 2 + ■ ■ ■ + Cn ■ X„) 

1=1 

unter Beachtung linearer Nebenbedingungen 

71 

^ ^ 0>ij * Xj ^ bi 

1 = 1 
n 

^ ^ 0>ij * Xj ^ bi 

1 = 1 
n 

^ij ' ^3 ~ 

1 = 1 

und meistens unter Beachtung von Nichtnegativitätsbedingungen 
Xj > 0 für (einige oder alle) j = 1, 2, . . . , n. 

Ein Beispiel für ein lineares Optimierungsproblem ist das so genannte klas- 
sische Transportproblem. Hierbei bieten mehrere Anbieter Ai (i = 1,2, , m) 
ein bestimmtes Gut in unterschiedlichen Mengen (a^ Mengeneinheiten) an, 
von dem mehrere Nachfrager Bj (j = 1, 2, . . . , n) jeweils die Menge bj benöti- 
gen. Es wird vorausgesetzt, dass ^1 güb d. h. die gesamte 

angebotene Menge des Gutes entspricht der Menge aller Nachfragen (Bedar- 
fe). Daneben sind die Kosten Cij für den Transport von einer Mengeneinheit 



für 1 = 1,..., TOi 
für i = TOi -I- 1, ... , m 2 
für i = TO 2 -I- 1 , . . . , m 
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des Gutes von Ai nach Bj bekannt. Gesucht ist ein kostenminimaler Trans- 
portplan, so dass alle Bedarfe bj befriedigt werden. 

Ein mathematisches Modell dieses Problems sieht wie folgt aus: 

m 71 

Minimiere F{x) = EE Cij ■ Xij 

i=l j=l 

unter den Nebenbedingungen 

n 

Xij = üi für i = 1, 2, . . . , TO 
i=i 

m 

Xij = bj für j = 1, 2, . . . , n 

i=l 

Xij > 0 für alle i und j, 

wobei die Variable Xij die Transportmenge von Ai nach Bj bezeichnet. 

Ein Spezialfall des Transportproblems mit m = n sowie = 1 und bj = 1 
für alle i und j ist das so genannte lineare Zuordnungsproblem. Ein stark 
idealisierter und vereinfachter Anwendungsfall dieses Problems ist die Zuord- 
nung von Export-Gontainern zu Import-Gontainern, die als Paar jeweils einen 
Transportauftrag für ein Portalhubfahrzeug definieren. Jeder Transportauf- 
trag wird über die zurückzulegende Entfernung (der Leerfahrt zwischen dem 
Abladen des Export-Gontainers und der Aufnahme des Import-Gontainers) 
bewertet. Hierbei muss beachtet werden, dass jedem Export-Gontainer genau 
ein Import-Gontainer zuzuordnen ist. Ziel ist die Minimierung der Summe al- 
ler zurückzulegenden Entfernungen. 

Ein mathematisches Modell für dieses Problem kann folgendermaßen for- 
muliert werden: 

n n 

Minimiere F{x) = EE Cij ■ Xij 

i=l j=l 

unter den Nebenbedingungen 

71 

Xij = 1 für i = 1,2, ... ,n 

71 

'^Xij = l für j = 1,2, ...,n 

i=l 

Xij G {0, 1} für alle i und j, 

wobei die Variable Xij genau dann den Wert 1 annimmt, wenn eine Zuord- 
nung von Export-Gontainer Ai zu Import-Gontainer Bj erfolgt. Dieses Zu- 
ordnungsproblem wird als linear bezeichnet, obwohl die dritte Nebenbedin- 
gungsgruppe zu einem binären Optimierungsmodell führt (d.h., es wird von 
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binären Variablen G {0, 1} ausgegangen), da es aufgrund seiner speziellen 
Struktur effizient exakt gelöst werden kann. 

Ein weiteres Beispiel aus der Klasse der binären Optimierungsmodelle 
ist das in Abschnitt 2.1.2 eingeführte Investitionsauswahlproblem: Jedes In- 
vestitionsvorhaben i, 1 < i < n, besitzt einen bestimmten Kapitalwert 
und verursacht Nettoauszahlungen au, die in Periode t, 1 < t < T, anfallen, 
wenn die jeweilige Investition i durchgeführt wird. Für jede Periode t ist ein 
maximales Budget bt vorgegeben. Ziel ist es, die Summe der Kapitalwerte 
aller ausgewählten Investitionen zu maximieren, wobei die Budgets in den 
einzelnen Perioden nicht überschritten werden dürfen. 

Dieses Problem kann folgendermaßen als mathematisches Modell abgebil- 
det werden: 

n 

Maximiere A(x) = E 6i • Xi 

i=l 

unter den Nebenbedingungen 



n 

^ ^ ' Xi 'G bt 

i=l 



Xi G {0,1} 



für t = 1,2,...,T 
für i = 1, 2, . . . , n. 



wobei die Variable Xi den Wert 1 annimmt, wenn die Investition i ausgewählt 
wird, ansonsten gilt Xi = 0. Da dieses Problem AfT^-schwer ist, sind keine 
effizienten exakten Verfahren zur Bestimmung einer optimalen Lösung be- 
kannt, weshalb gegebenenfalls heuristische Lösungsverfahren eingesetzt wer- 
den müssen; vgl. Abschnitt 2.1.3. 



4.8 Übungen 

4.8.1 Unternehmensmodellierung 

1. Stellen Sie Zusammenhänge zwischen den Grundsätzen ordnungsmäßiger 
Modellierung und Meta-Modellen her! 

4.8.2 Entity-Relationship-Modellierung 

1. Ergänzen Sie das Entity-Relationship-Modell aus Abbildung 4.17 auf 
S. 115 durch (min,max)-Beziehungskomplexitäten! 

2. Zur Zeit finanzieren Sie Ihr Studium als EDV-Berater bei einem 
Pizzabringdienst. Aufgrund seiner guten Pizzen fallen immer mehr 
Bestellungen an, so dass die wachsende Zahl an Zetteln zu einem Chaos 
in der Küche geführt hat. Eine Lösung verspricht sich der Inhaber des 
Pizzabringdienstes durch die Verwendung einer Datenbank, mit der 
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alle Bestellungen und Lieferungen verwaltet werden können. Dazu liegt 
Ihnen folgender zu modellierender Wirklichkeitsausschnitt vor: 

Der Pizzabringdienst bietet verschiedene Pizzen an (gekennzeichnet 
durch eine Nummer). Jede Pizza besteht aus Teig, Tomaten, Käse 
und diversen Zutaten (Salami, Schinken, Pilze usw.). Die Zutaten zu 
einer Pizza sind fest vorgegeben; eine maximale Anzahl an (möglichen) 
Zutaten ist jedoch nicht vorgegeben. Es gibt eine Kundendatei, in der die 
Kunden vermöge ihrer Telefonnummern eindeutig identifiziert werden. 
Jede Bestellung kommt von genau einem Kunden, umfasst beliebig viele 
Pizzen (aber mindestens eine) und wird von einem Fahrer ausgeliefert. 
Die Bestellungen werden durch eine fortlaufende Bestellnummer identi- 
fiziert. Auf einer Tour kann ein Fahrer mehrere Bestellungen ausliefern. 
Erstellen Sie ein ER-Modell mit den wesentlichen Informationen 
Objekttypen, Beziehungstypen, (Schlüssel-)Attribute, (min,max)-Be- 
ziehungskomplexitäten! Beschränken Sie sich dabei auf das einfache 
ER-Modell ohne IS-A-Beziehungen und existenzielle/identifikatorische 
Abhängigkeiten ! 

3. Ein Kommilitone von Ihnen - Student im 9. Semester, Entrepreneur 
und angehender Top-Manager - hat folgende geniale Geschäftsidee: 
ein Verleih von Computersystemen an (wegen der eingeschränkten 
Rechnerausstattung der Universität leidgeprüfte) Studenten. Aufgrund 
der attraktiven Zielgruppe kann er Hard- und Softwarehersteller 
dafür gewinnen, hierbei Werbemaßnahmen durchzuführen, was es ihm 
ermöglicht, die Computersysteme zu sehr attraktiven Konditionen 
zu verleihen. Nachdem Finanzierung, Marketing und Beschaffung der 
Computersysteme geklärt sind, wächst ihm die Aufgabe über den Kopf, 
weshalb er Sie aufgrund Ihrer Wirtschaftsinformatikkenntnisse für die 
organisatorische und informationstechnische Abwicklung einstellt. Er 
schildert Ihnen folgenden Realitätsausschnitt, der in einer Datenbank 
abgebildet werden soll: 

Es werden verschiedene Arten kompletter (nicht variierbarer) Compu- 
tersystemtypen zum Verleih angeboten. Ein Computersystemtyp ist 
durch eine Typnummer gekennzeichnet und besitzt Eigenschaften wie 
insbesondere Prozessor und Monitor. Von einem Computersystemtyp 
sind in der Regel mehrere Exemplare vorhanden, die durch eine Exemp- 
larnummer identifiziert sind. Die Geschäftsidee soll in allen deutschen 
Universitäten umgesetzt werden. Ein konkretes Computersystem (E- 
xemplar) ist immer genau einer Universität zugeordnet, bei der es zur 
Ausleihe bereit steht. Ein Entleiher (Student) soll in die Datenbank mit 
seinem Namen, seiner Telefonnummer sowie seiner Kreditkartennummer 
aufgenommen werden (von diesen Eigenschaften ist ausschließlich 
die Kreditkartennummer kennzeichnend und damit als Schlüssel zu 
verwenden). Ferner muss abgebildet werden, an welcher (genau einer) 
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Universität der Student studiert. Für jede Universität ist neben dem 
eindeutigen Namen die Studierendenanzahl als Eigenschaft in das Modell 
zu übernehmen. Bei einem Entleihvorgang muss festgehalten werden, 
welcher Student welches Computersystem bis wann ausgeliehen hat. 
Sofern alle Computersysteme eines gewünschten Typs ausgeliehen sind, 
kann der Student den entsprechenden Computersystemtyp vorbestellen; 
hierbei ist abzubilden, in welcher Reihenfolge die Wünsche eingehen, um 
das erneute Verleihen zurückgegebener Computersysteme entsprechend 
dieser Reihenfolge vornehmen zu können. 

Erstellen Sie ein ER-Modell mit den wesentlichen Informationen 
Objekttypen, Beziehungstypen, (Schlüssel-)Attribute, (min,max)-Be- 
ziehungskomplexitäten! Beschränken Sie sich dabei auf das einfache 
ER-Modell ohne IS-A-Beziehungen und existenzielle/identifikatorische 
Abhängigkeiten! 

4. Ein möglicher Organisationstyp der Fertigung ist die Fließfertigung.^^ 
Hierbei werden die Produktiveinheiten entsprechend der Reihenfolge der 
an einem Produkt durchzuführenden Arbeitsgänge hintereinander ange- 
ordnet. Die Produktiveinheiten bezeichnet man in diesem Zusammen- 
hang als (Bearbeitungs-)Stationen. 

Gehen Sie davon aus, dass der (mehrstufige) Produktionsprozess für jedes 
in der Fließfertigung herzustellende Produkt (Auftrag) in mehrere Ar- 
beitsgänge zerlegt werden kann, die jeweils als unteilbar angesehen wer- 
den. Jedem Arbeitsgang ist eine Bearbeitungszeit zugeordnet. Aufgrund 
technologischer Restriktionen können zwischen Arbeitsgängen zeitliche 
Vorrangrestriktionen (Reihenfolgebeziehungen) bestehen, die mittels ei- 
nes Vorranggraphen dargestellt werden können. 

Zur Verdeutlichung sei als vereinfachtes Beispiel die Produktion verschie- 
dener Autotypen an einem Fließband genannt. Es gibt produktspezifisch 
jeweils verschiedene Arbeitsgänge, die gewissen Reihenfolgerestriktionen 
unterliegen (z. B. erst Rahmen lackieren, dann Räder montieren). Die 
Autos sollen an einem Fließband gefertigt werden, das sich jeweils nach 
einer festzulegenden Taktzeit vorwärts bewegt; an dem Fließband werden 
verschiedene Arbeitsstationen angeordnet. 

Das grundlegende Fließbandabstimmungsproblem {Assembly Line Ba- 
lancing Problem) besteht darin, eine Fließbandproduktion so zu konfigu- 
rieren, dass bestimmte Zielsetzungen erreicht werden. Unter Konfigura- 
tion sei hier die Bildung einer Menge von Arbeitsstationen und die ent- 
sprechende Zuordnung von Arbeitsgängen zu Arbeitsstationen im Rah- 
men einer Produktionsplanung verstanden. 

Um diese Problemstellung mit entsprechenden Optimierungs verfahren 
„lösen“ zu können, benötigt man zunächst die grundlegenden relevanten 
Daten; weiterhin sollen „Lösungen“ (d.h. z. B. die Zuordnung von Ar- 



12 



Vgl. u. a. Domschke et al. (1997). 
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beitsgängen zu Stationen) abgebildet werden. Hierzu sind im Folgenden 
die wesentlichen Informationen zusammengefasst, die abgebildet werden 
sollen. 

• Es gibt verschiedene Produkte. Zu jedem Produkt existiert eine spezifi- 
sche Menge von Arbeitsgängen, die ausgeführt werden müssen. Es gibt 
Reihenfolgerestriktionen derart, dass für bestimmte Arbeitsgangpaare 
eine Reihenfolge vorgegeben ist. 

• Für Produkte und Arbeitsgänge gibt es textuelle Bezeichnungen und 
(als Schlüssel verwendbare) Zahlencodes. Jeder Arbeitsgang ist genau 
einem Produkt zugeordnet und benötigt eine bestimmte Bearbeitungs- 
zeit. 

• Für eine Lösung ist insbesondere die Zuordnung von Arbeitsgängen zu 
Stationen relevant. Stationen seien durch eindeutige Nummern identi- 
fiziert. 

• Es gibt verschiedene Maschinentypen (gekennzeichnet durch Namen, 
produziert von einem Hersteller). Von diesen existieren gegebenen- 
falls mehrere Exemplare (gekennzeichnet durch Inventarnummern), die 
bei einer „Lösung“ Stationen zugeordnet werden. Zur Durchführung 
von Arbeitsgängen werden in der Regel Maschinen bestimmter Typen 
benötigt. 

Erstellen Sie ein ER-Modell mit den wesentlichen Informationen 
Objekttypen, Beziehungstypen, (Schlüssel-)Attribute, (min,max)-Be- 
ziehungskomplexitäten! Beschränken Sie sich dabei auf das einfache 
ER-Modell ohne IS-A-Beziehungen und existenzielle/identifikatorische 
Abhängigkeiten ! 



4.8.3 Prozessmodellierung 

1. Bilden Sie den folgenden Ablauf bei der Mobilfunkantragsprüfung eines 
Mobilfunkproviders als eine Ereignisgesteuerte Prozesskette ab! 

Da das Unternehmen eine Kostenführerschaft im Markt anstrebt, ist 
der Antragseingang auf das Internet beschränkt. Eingegangene Anträge 
werden zunächst auf Konsistenz und Vollständigkeit geprüft; ergeben 
sich hierbei Defizite, wird der Antrag abgelehnt. Ansonsten erfolgen die 
im Weiteren beschriebenen Prüfungen, die jeweils parallel zueinander 
ablaufen: Sofern es sich um einen Mobilfunkvertrag mit einer Monats- 
grundgebühr handelt, muss eine Kreditwürdigkeitsprüfung stattfinden, 
die bei Verträgen ohne Monatsgrundgebühr („Prepaid“) entfällt. Sofern 
die Kreditwürdigkeit als nicht ausreichend bewertet wird, wird der 
Auftrag abgelehnt. Es wird immer geprüft, ob der Antragsteller bereits 
einen aktuell bestehenden Mobilfunkvertrag bei dem Unternehmen 
besitzt; in einem solchen Fall wird der Antrag abgelehnt. Abschließend 
wird dem Kunden per E-Mail die Ablehnung oder Akzeptanz des 
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Antrags mitgeteilt. 

2. Bilden Sie den folgenden Ablauf in einer Kantine in einem Stellen- 
Transitions-Petri-Netz ab! (Ergänzen Sie hierbei das Diagramm durch 
kurze Bezeichnungen, so dass deutlich wird, was die Stellen bzw. 
Transitionen abbilden!) 

Neue Kunden kommen durch eine Eingangstür, die als Systemgrenze 
betrachtet wird, und damit als eine objekterzeugende Transition ab- 
gebildet werden kann. Dieses gilt in umgekehrter Form analog für die 
Ausgangstür zum Verlassen der Kantine. Die Kunden entscheiden sich 
für eines von zwei Komplettgerichten, für die jeweils eine eigene War- 
teschlange existiert, die jeweils maximal 10 Kunden aufnehmen kann. 
Der Vorrat an auszugebenden Komplettgerichten ist durch jeweilige 
Objektreservoirs abzubilden. Die zwei Ausgaben für die Gerichte werden 
durch lediglich eine Bedienstete betreut, die je nach Andrang an den 
einzelnen Ausgaben tätig wird. Nach Empfang des Hauptgerichtes reihen 
sich die Kunden in eine einzige Kassenwarteschlange ein (Kapazität 15 
Kunden). Nach der Kasse nehmen die Kunden ihre Mahlzeit in einem 
Essensraum mit 150 Plätzen ein und verlassen anschließend die Kantine. 

3. Transformieren Sie die in Abbildung 4.25 (S. 123) dargestellten Ereignis- 
gesteuerten Prozessketten in entsprechende Petri-Netze! 

4.8.4 Simulation 

1. Der Vorsitzende des IOC befürchtet, dass bei den kommenden Olym- 
pischen Spielen zu den Wettkämpfen im Olympiastadion die Anzahl 
der Einlassmöglichkeiten nicht ausreichend ist, so dass möglicherweise 
ein Teil der Zuschauer erst nach Beginn der Wettkämpfe ins Stadion 
gelangen kann. Er gibt Ihnen daher den Auftrag, dies zu überprüfen. Sie 
entscheiden sich, die Einlasskontrolle zu simulieren. 

Vorhanden sind 20 Eingänge, wovon einer für Rollstuhlfahrer ausgewie- 
sen ist. Es ist ferner bekannt, dass die Kontrolle einer Eintrittskarte zwei 
Sekunden dauert. Weiterhin sind Erwartungswerte für die Eintreffzeit- 
punkte der Zuschauer bekannt. 

Erläutern Sie anhand des obigen Beispieles die vier wesentlichen Schritte 
bei der Simulation! 

2. Im Vorfeld einer Großveranstaltung in Ihrer Stadt wird aufgrund der 
nicht ausreichenden Hotelkapazität ein Zimmervermittlungssystem auf- 
gebaut, wodurch über ein Informationssystem Gäste an von privaten 
Gastgebern zur Verfügung gestellte Zimmer vermittelt werden sollen. 
Hierzu ist eine Strategie zur Zuordnung von Gästen zu Zimmern (und 
somit zu Gastgebern) zu entwickeln bzw. zu bewerten. Die Vermittlung 
soll auf Basis von Fragebögen stattfinden, die zuvor von Gastgebern 
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und Gästen auszufüllen sind. Sowohl die Gäste wie auch die Gastgeber 
müssen ihren Fragebogen (und somit ihre Übernachtungswünsche bzw. 
Zimmerangebote) spätestens zwei Monate vor Beginn der Großveranstal- 
tung abgegeben haben; anderenfalls werden die Anmeldungen nicht mehr 
berücksichtigt. Eine Zuordnung von Gästen zu Zimmern erfolgt von dem 
Moment an, zu dem die ersten Anmeldungen vorliegen. Somit ist die 
Zuordnung der Gäste zu den Zimmern abgeschlossen, bevor die Großver- 
anstaltung beginnt, so dass die Gäste, die nicht zugeordnet werden konn- 
ten, noch etwas Zeit haben, sich eine andere Übernachtungsmöglichkeit 
zu suchen. 

Gemeinsam mit Ihrem Ghef nehmen Sie sich des Zimmervermittlungssys- 
tems an. Ihr Ghef hat sich für die Zuordnung die folgenden drei Regeln 
ausgedacht. 

i. Die Zuordnung von Gästen zu Zimmern erfolgt, sobald sich ein neu- 
er Gast beim Informationssystem anmeldet bzw. ein Gastgeber ein 
neues Zimmer beim Informationssystem zur Verfügung stellt. 

ii. Steht für den neuen Gast ein (geeignetes) Zimmer zur Verfügung 
bzw. existiert für das neue Zimmer ein (geeigneter) Gast, so erfolgt 
die Zuordnung; ansonsten wird der neue Gast bzw. das neue Zimmer 
in eine Warteschlange eingetragen. 

iii. Existieren mehrere Zuordnungsmöglichkeiten, so wird dem am längs- 
ten wartenden Gast oder Zimmer der Vorrang gegeben. 

Um die Güte dieser Regeln festzustellen, haben Sie sich überlegt, eini- 
ge Simulationsexperimente durchzuführen, um Ihren Ghef dann mit den 
Ergebnissen zufrieden zu stellen oder dessen Ghef davon zu überzeugen, 
dass die Planung in andere (Ihre) Hände gehört. Für die Experimente 
stehen Ihnen folgende Daten zur Verfügung. 

Die Anzahl zu erwartender Gäste und zur Verfügung stehender Zimmer 
wurde durch Voruntersuchungen in einer früheren Phase des Projektes 
bestimmt, ebenso Wahrscheinlichkeitsverteilungen bzgl. der Zeitpunkte, 
zu denen sich Gäste frühestens anmelden oder Gastgeber ein Zimmer zur 
Verfügung stellen. Gehen Sie für Ihr erstes Experiment vom folgenden 
(vereinfachten) Beispieldatensatz aus: 

Es werden zuerst nur diejenigen Gäste und Zimmer zugeordnet, die für die 
gesamte Dauer der Großveranstaltung angemeldet werden. Somit müssen 
zeitliche Begrenzungen nicht berücksichtigt werden. Es existieren hiervon 
vier Gäste (mit Gl, G2, G3 und G4 bezeichnet) sowie vier Zimmer (mit 
ZI, Z2, Z3 und Z4 bezeichnet). 

Die Anmeldezeitpunkte an das Informationssystem (d. h. die Zeitpunk- 
te, zu denen die Fragebögen ankommen) können der folgenden Tabelle 
entnommen werden: 



Person / Zimmer 


Gl 


G2 


ZI 


Z2 


G3 


Z3 


G4 


Z4 


Anmeldezeitpunkt 


1 


3 


7 


8 


19 


20 


23 


29 
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Aufgrund der Fragebögen sind in unserem Beispiel (z.B. wegen der 
Rauchgewohnheiten, des Alters usw.) nur folgende Zuordnungen möglich: 
Gl - Z2, Gl - Z3, Gl - Z4, 

G2 - ZI, G2 - Z2, G2 - Z3, 

G3 - ZI, G3 - Z3, 

G4 - Z3. 



a) Geben Sie alle für die ereignisorientierte Simulation relevanten 
Zeitpunkte an und stellen Sie eine Ereignisliste auf (z.B. gemäß 
nachstehender Tabelle) ! 



Zeitpunkt 


Aktion 


Warteschlange G 


Warteschlange Z 


1 


Eintritt Gl 


Gl 


- 











b) Können alle Gäste zugeordnet werden? 

c) Eine Reihe von Simulationsexperimenten hat aufgezeigt, dass die 
oben angegebenen Regeln zur Bestimmung von Zuordnungen zu 
suboptimalen Zuordnungen führen (vgl. hierzu auch das Ergebnis 
des von Ihnen durchgeführten Experimentes). Im Rahmen von 
Simulationsstudien schließt sich an die Experimentierphase in der 
Regel die Ergebnisanalyse sowie eine Modellbewertung und die 
Verbesserung eingesetzter Strategien an. 

Welche Regel ist zu verändern, um generell eine breitere Ent- 
scheidungsgrundlage für das Zuordnungsproblem zu erhalten? 
Hilfestellung: Bis zu welchem Zeitpunkt muss die Zuordnung von 
Gästen zu Zimmern mindestens hinausgezögert werden, damit G4 
überhaupt zugeordnet werden kann (unter der Annahme, dass keine 
weiteren Zimmer gemeldet werden)? 

d) Welche zusätzliche(n) Regel(n) ist (sind) denkbar, um möglichst 
viele Paare bilden zu können (damit z.B. auch G4 ein Zimmer 
erhält)? Hier genügt die Beschreibung eines einfachen Algorithmus 
bzw. einer einfachen Vorgehensweise. 

e) Zeigen Sie anhand der von ihnen aufgestellten Regeln, dass alle 
Gäste im Beispiel ein Zimmer bekommen! Erzeugen Sie hierzu 
ebenfalls eine Ereignisliste in Tabellenform wie in Teilaufgabe a)l 

3. Um zu überprüfen, ob seine Mitarbeiter(innen) wirklich so überlastet 
sind, wie diese immer behaupten und somit die Betreuungsqualität für 
Studierende leidet, beschließt Professor X, dies mittels eines (diskre- 
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ten, ereignisorientierten) Simulationsmodells bzw. -experimentes zu über- 
prüfen. Damit soll zunächst der Ablauf der normalen Mitarbeitersprech- 
zeiten (Do., 11-12 Uhr) simuliert werden. 

Die Ankünfte der Studierenden werden über Zufallszahlenströme abge- 
bildet. Dabei werden 3er-Tupel (a,b,c) verwendet, denen folgende Bedeu- 
tung zugeordnet ist: 

a: Ankunftszeitpunkt (ab 11 Uhr, zwischen 0 und 60 [Minuten]) 
b: Sprechzeitbedarf (zwischen 5 und 60 [Minuten]) 
c: Geschlecht (m=männlich, w=weiblich) 

Vereinfachenderweise seien Annahmen getroffen, dass Studierende immer 
einzeln zur Sprechzeit kommen und die beiden Mitarbeiter von Professor 
X (ein männlicher Mitarbeiter M, eine weibliche Mitarbeiterin W) identi- 
sche Kenntnisse besitzen. Studierende entscheiden sich bei Ankunft nach 
folgender Entscheidungsregel, zu wem sie gehen: 

• Wenn eine Warteschlange kürzer ist, gehen Studierende dorthin. 

• Wenn beide Warteschlangen gleich lang sind, gehen Studentinnen zum 
Mitarbeiter M und Studenten zur Mitarbeiterin W. 

(Zu Professor X trauen sich die Studierenden (noch) nicht.) 

Hierbei sei die Länge von Warteschlangen als die Anzahl wartender Stu- 
dierender inklusive des/der gegebenenfalls gerade beratenen Studieren- 
den definiert. Weiterhin wird angenommen, dass die Warteschlangen 
(WM und WW) streng nach dem FIFO-Prinzip (First In, First Out) 
„abgearbeitet“ werden. Außerdem sei angenommen, dass auf jeden Fall 
alle Studierenden, die vor 12 Uhr eintreffen, auch noch „abgearbeitet“ 
werden. 

a) Simulieren Sie manuell den Ablauf einer Mitarbeitersprechzeit 
am Lehrstuhl von Professor X unter Verwendung des folgenden 
Zufallszahlenstromes, der die eintreffenden Studierenden abbildet 
(Ankunftszeit in Minuten nach 11 Uhr): 



Ankunftszeit 


0 


10 


25 


35 


40 


50 


55 


Dauer 


30 


10 


50 


10 


60 


20 


5 


Geschlecht 


ml 


m2 


w3 


w4 


m5 


w6 


w7 



(Die Ziffer nach m bzw. w dient zur einfacheren Identifizierung der 
Studierenden.) Geben Sie den aktuellen Zustand zu jedem diskreten 
Zeitpunkt, an dem ein abgebildetes Ereignis stattfindet (d. h. eine 
Veränderung einer Warteschlange über einen Zu- oder Abgang) , über 
die Vervollständigung der vorgegebenen untenstehenden Tabelle an! 
Bei Bedarf können Sie das nachfolgende Diagramm verwenden. 
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M 




m2 




w 


ml 

— ^ ^ — 


— ^ ^ ^ ^ ^ ^ ^ ^ ^ 



10 20 30 40 50 60 70 80 90 100 110 120 



Zeit 


Ereignis 


WM 


WW 


0 


Ankunft ml, Zugang WW 


- 


ml 


10 


Ankunft m2, Zugang WM 


m2 


ml 











b) Schafft es Mitarbeiter M, rechtzeitig um 12:30 Uhr in der Mensa zu 
sein, wo er sich verabredet hat? 



4.8.5 Mathematische Modellierung 

1. Ein Handwerksbetrieb, der bisher alle Nachrichten (an Kunden, Lie- 
feranten usw.) immer mittels Briefpost verschickt hat, überlegt, ob 
sich die Anschaffung eines Faxgerätes oder eines Internetzuganges zur 
Versendung von Faxen bzw. E-Mails lohnen würde. Der Geschäftsführer 
bittet Sie, ihm „die beste Lösung“ (Zitat) für diese Entscheidung 
zu präsentieren. Das Problem stellt sich demnach (stark vereinfacht) 
folgendermaßen dar: 

Es stehen drei Kommunikationsmittel zur Auswahl (Briefpost, Fax, 
E-Mail). Für diese Kommunikationsmittel fallen gegebenenfalls Fix- 
kosten (für Anschaffung, Installation und Betrieb, z.B. monatliche 
Grundgebühr für den Internetzugang) an, dies jedoch nur, falls das 
Kommunikationsmittel tatsächlich genutzt werden soll (und damit 
angeschafft werden muss). Weiterhin ist bekannt, welche Nachrichten 
in welchem Umfang gesendet werden müssen und welche Kommuni- 
kationsmittel dafür in Frage kommen (hinsichtlich der vorhandenen 
Endgeräte bei den Empfängern). Das heißt, es gibt eine Menge von zu 
versendenden Nachrichten; zu jeder dieser Nachrichten sind der Umfang 
und die möglichen Kommunikationsmittel gegeben. Außerdem sind die 
variablen Kosten für die Versendung einer Nachricht bekannt, die vom 
Umfang der Nachricht und dem verwendeten Kommunikationsmittel 
abhängen (z.B. Briefporto in Abhängigkeit vom Gewicht, d.h. dem 
Umfang der Nachricht). 

Erstellen Sie für dieses Problem ein mathematisches Optimierungsmo- 
dell, bei dem die Zielsetzung darin besteht, die Gesamtkosten (d. h. 
die Summe aller variablen Kosten für die Versendung der Nachrichten 
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zuzüglich der Summe der Fixkosten für die tatsächlich verwendeten 
Kommunikationsmittel) zu minimieren! 

2. Im Gallien des Jahres 50 v. Chr. gründet Obelix eine Hinkelstein- 
Fabrik: die Obelix GmbH & Go. KG; siehe hierzu Scholl und Klein 
(1997). Dabei steht er vor einem Investitionsauswahlproblem, da er 
Kundenanfragen für sechs unterschiedliche Hinkelsteintypen bekommen 
hat, die jeweils einer Investition (z. B. in Werkzeuge) entsprechen. Hätte 
es zu dieser Zeit bereits die Rechentechnik von heute gegeben, hätte 
Obelix vermutlich versucht, sich die Investitionsentscheidung durch eine 
Softwareunterstützung zu erleichtern: 

a) Erstellen Sie mittels einer Tabellenkalkulationssoftware (z.B. 
Microsoft Excel) ein Datenblatt, das das Investitionsauswahl- 
problem widerspiegelt! Insbesondere sollte eine variable Eingabe 
der Investitionsentscheidung möglich sein und auf deren Basis 
die Berechnung der Summe der Kapitalwerte sowie der mit den 
Investitionen verbundenen Nettoauszahlungen in allen Perioden 
automatisiert durchgeführt werden. Falls die von Ihnen verwendete 
Tabellenkalkulationssoftware eine Optimierungsfunktionalität be- 
sitzt (bei Microsoft Excel wäre dies der „Solver“), dann verwenden 
Sie diese, um zu versuchen, eine optimale Lösung für das Problem 
zu bestimmen. 

b) Da mit Hilfe einer Tabellenkalkulationssoftware nur ein konkretes 
Investitionsauswahlproblem modelliert werden kann, derartige Prob- 
leme jedoch immer wieder auftreten, bietet es sich an, ein allgemeines 
Modell zu erstellen, bei dem von den konkreten Eingabewerten (Pa- 
rametern, z. B. Anzahl möglicher Investitionen oder Werte für Netto- 
auszahlungen) abstrahiert wird. Ein derartiges Modell könnte dann 
im Zusammenhang mit einer speziellen Optimierungssoftware (z.B. 
der ILOG Optimization Suite; vgl. http://www.ilog.com) verwen- 
det werden, so dass bei anderen Investitionsauswahlproblemen jeweils 
nur die konkreten Eingabedaten, nicht jedoch die Struktur des Prob- 
lems in die Software eingegeben werden müssten. 

Erstellen Sie deshalb mit Hilfe einer mathematischen Modellierungs- 
sprache (z.B. einer Demoversion von AMPL; siehe http;//www. 
ampl . com) ein Modell für ein allgemeines Investitionsauswahlprob- 
lem! 
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Datenbanksysteme bilden einen zentralen Bestandteil typischer betrieblicher 
Anwendungssysteme. Im Folgenden werden zunächst die typische Architektur 
von Datenbanken bzw. Datenbanksystemen sowie das Transaktionskonzept 
erläutert. Daraufhin werden relationale Datenbanken sowie die hierauf basie- 
rende Datenbankabfragesprache SQL dargestellt. Abschließend wird auf das 
Data-Warehouse-Konzept sowie auf weitere Aspekte des Datenmanagements 
eingegangen. ^ 



5.1 Architektur 

Ein Datenbanksystem besteht aus einem einheitlich definierten Datenbestand 
(Datenbank) und einem Datenbankmanagementsystem (DBMS), das diesen 
Datenbestand verwaltet. Ein Zugriff auf die Daten ist nur über das DBMS 
nach dessen Kriterien (hinsichtlich Datenintegrität und -Sicherheit, Synchro- 
nisation usw.) möglich. Der Zugriff von Anwendungsprogrammen bzw. Nut- 
zern auf die Datenbank kann damit gemäß des Client-Server-Konzeptes struk- 
turiert werden; vgl. Abbildung 5.1 sowie Abschnitt 2.5.1. 




Abbildung 5.1. Zugriff auf Datenbanken 



^ Für detaillierte Darstellungen zum Thema Datenbanken verweisen wir auf z.B. 
Elmasri und Navathe (2003), Heuer und Saake (2000) sowie Vossen (2000). 
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Für die Strukturierung der eigentlichen Datenbank hat sich das 
ANSI/X3/SPARC-ArchitekturmodelP durchgesetzt. Hierbei wird die Da- 
tenbank in drei Abstraktionsebenen unterteilt: die interne, die konzeptio- 
nelle und die externe Ebene. Diese Ebenen sind in Abbildung 5.2 im Zu- 
sammenhang mit entsprechenden Datenbankmanagementoperationen sche- 
matisch dargestellt. 



Abstraktionsebene zugeordnete Operationen 




Abbildung 5.2. Datenbankarchitekturmodell 



In der internen Ebene sind die eigentlichen Datenstrukturen zur physi- 
schen Speicherung der Daten auf Speichermedien fest gelegt. Hierzu gehören 
z.B. die interne Sortierung der Daten sowie Zugriffspfade für einen effizien- 
ten Datenzugriff. Die in diesem Rahmen zu treffenden Festlegungen erfolgen 
im Rahmen der Datenadministration, die in der Regel abhängig von dem 
verwendeten Datenbankmanagementsystem ist. 

Auf der konzeptionellen (konzeptuellen) Ebene ist in einem entsprechen- 
den logischen Datenmodell (Schema) eine abstrakte Gesamtsicht auf die Da- 
ten definiert. Die konkrete Art der Datendefinition ist abhängig vom zu 
Grunde gelegten Metadatenmodell. Hier dominieren in der Praxis die in 
Abschnitt 5.3 beschriebenen relationalen Datenbanken bzw. das entspre- 
chende Relationenmodell. Im Rahmen der Entwicklung von Datenmodellen 
kann man insbesondere das in Abschnitt 4.2 dargestellte Entity-Relationship- 
Modell verwenden. 

Durch externe Schemata werden auf der externen Ebene spezifische Sich- 
ten ( Views) auf das logische Datenmodell definiert. Hiermit werden verschie- 
denen Anwendungen die jeweils relevanten Ausschnitte der Datenbasis zur 
Verfügung gestellt. Beispielsweise benötigt eine Personal verwaltungsanwen- 

^ ANSI: American National Standards Institute; SPARC: Standards Planning and 
Requirements Committee. 
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düng einer Fluggesellschaft Daten der Fluggesellschaftsangestellten, nicht je- 
doch Daten zu Passagieren und Flugzeugtypen. 

Durch die Strukturierung von Datenbanken in drei aufeinander aufbauen- 
de Schichten erreicht man eine gewisse Trennung zwischen den Anforderungen 
spezifischer Anwendungen, dem logischen Gesamtmodell und der physischen 
Speicherung der Daten (logische und physische Datenunabhängigkeit). Die 
eigentliche Umsetzung zwischen den verschiedenen Ebenen wird durch das 
DBMS auf der Grundlage von in einem zentralen Datenkatalog {Data Dictio- 
nary) abgebildeten Metainformationen über den Datenbestand durchgeführt. 



5.2 Transaktionskonzept 

Auf den in einer Datenbank enthaltenen Daten können so genannte Trans- 
aktionen durchgeführt werden. Unter einer Transaktion versteht man eine 
Folge von Datenbankoperationen, die hinsichtlich gewisser Integritätsanfor- 
derungen als atomare Einheit anzusehen sind. Datenbanken müssen vor und 
nach der Ausführung von Transaktionen in einem konsistenten Zustand sein. 

Als Beispiel für eine Transaktion sei die Ausführung einer Umbuchung 
eines Betrages A zwischen zwei Konten A und B genannt. Hierfür werden 
folgende Datenbankoperationen durchgeführt: 

1. Lesen des Kontostandes von A-. Ka 

2. Schreiben des neuen Kontostandes Ka — A 

3. Lesen des Kontostandes von B: Kb 

4. Schreiben des neuen Kontostandes Kß -\- A 

Nach der zweiten Datenbankoperation (Schreiben des neuen Kontostandes 
von A) ist der Zustand der Datenbank temporär inkonsistent, da nur ein 
Teil der Transaktion durchgeführt wurde. Die Konsistenz der Datenbank ist 
erst wieder nach der letzten Datenbankoperation hergestellt, weshalb sicher- 
zustellen ist, dass die vier Datenbankoperationen der Transaktion logisch 
zusammen ausgeführt werden. 

Ein DBMS hat - unter Berücksichtigung der Möglichkeit des Auftretens 
von Fehlern ~ folgende Bedingungen zu gewährleisten, die einen konsisten- 
ten Zustand der Daten über eine korrekte Ausführung von Transaktionen 
garantieren {ACID-Prinzip): 

• Atomarität (Atomarity): 

Transaktionen werden entweder vollständig oder gar nicht durchgeführt. 
Somit darf z. B. die obige Umbuchung zwischen Konten nicht unvollständig 
ausgeführt werden. 

• Konsistenz (Consistency): 

Alle Integritätsbedingungen der Datenbank werden nach der Ausführung 
einer Transaktion eingehalten. Beispielsweise ist eine doppelte Vergabe von 
Schlüsselattributen nicht möglich. 
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• Isolation: 

Transaktionen laufen isoliert von anderen (potenziell parallelen) Transak- 
tionen ab. Wenn z. B. zwei Programme P\ und P 2 direkt hintereinander 
einen Kontostand K ablesen, um eine Gutschrift zu verbuchen {P\ mit 
einer Gutschrift von 100 €, P 2 mit einer Gutschrift von 200 €), dann er- 
geben sich zwei Schreiboperationen, nämlich K + 100 und K + 200. Das 
DBMS muss über eine geeignete Synchronisation sicherstellen, dass am 
Ende K + 300 als Kontostand resultiert. 

• Persistenz (Durability): 

Abgeschlossene Transaktionen müssen alle nachfolgenden Fehler überleben 
(auch wenn die Daten nur in einem Zwischenpuffer (Gache) liegen). 



5.3 Relationale Datenbanken 

Relationale Datenbanken basieren auf dem relationalen Datenmodell von 
Godd (1970). Dessen Grundidee besteht darin, zur Darstellung der zu mo- 
dellierenden Wirklichkeit ein einziges Konstrukt zu verwenden: Relationen. 
Eine Relation R bezeichnet eine Teilmenge des kartesischen Produktes einer 
Liste von Wertebereichen: R C Di x D 2 x . . . x Dn, wobei Di x D 2 x . . . x 
die Menge aller Tupel {vi,V 2 , ■ ■ ■ , u„) mit Grad n ist, bei denen vi ein Wert 
aus Dl, V 2 ein Wert aus D 2 usw. ist. 

Relationen können als Tabellen betrachtet werden. Ein Tabellenkopf gibt 
dann die Bezeichnung der Attribute an (d. h. die Bedeutung der Werteberei- 
che Dl, D 2 , ■ ■ ■ , Dn). Die Zeilen (Tupel) entsprechen konkreten Ausprägun- 
gen dieser Wertebereiche. Tabelle 5.1 zeigt ein Beispiel für eine Relation. 



Personen-Nr 


Nachname 


Vorname 


457843 


Kämmerer 


Kai 


324903 


Mies 


Andreas 


320444 


Reiners 


Torsten 


230243 


Haller 


Oliver 


324434 


Loos 


Nicole 



Tabelle 5.1. Relation PERSONEN 



Auf Relationen können mittels einer Relationenalgehra Operationen 
durchgeführt werden. Diese nehmen einige Relationen als Input und erzeugen 
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als Output neue Relationen.^ Für eine vollständige Ausdruckskraft werden 
die folgenden fünf Basisoperationen benötigt:"^ 

• Kartesisches Produkt (von Relationen) 

• Projektion (von bestimmten Attributen einer Relation) 

• Selektion (bestimmter Tupel einer Relation über eine Bedingung) 

• Vereinigung (von Relationen) 

• Differenz (von Relationen) 

Aus diesen Basisoperationen können andere Operationen abgeleitet werden. 

Zur Erläuterung der Basisoperationen soll das Beispiel eines Kreditinsti- 
tutes mit mehreren Filialen, Kunden und (natürlich) Krediten dienen. Als 
Relationen (Tabellen) seien gegeben: 

KUNDE ( KName . KStraße, KStadt) 

KREDIT (Filiale, Kredit# , KNernie, Betrag) 

Die unterstrichenen Attribute stellen hierbei so genannte Schlüsselattribu- 
te dar, die der eindeutigen Identifizierung eines Objektes dienen. Schlüssel 
können sich auch aus mehreren Attributen zusammensetzen. 

Uber eine Selektion z. B. kann man Abfragen der Art „Finde alle Kunden 
aus der Stadt Hamburg“ beantworten: SelektionKstadt=Hamburg (KUNDE). Hier- 
durch werden aus der Relation (Tabelle) KUNDE alle Tupel (Zeilen) ermittelt, 
bei denen das Attribut (die Spalte) KStadt die Ausprägung Hamburg besitzt. 

Sollen nicht alle Attribute der Kunden, sondern z. B. nur ihre Namen 
ermittelt werden („Finde alle Namen von Kunden aus der Stadt Hamburg“), 
so muss zusätzlich zur Selektion eine Projektion durchgeführt werden: 
ProjektionKName (SelektionKStadt=Hamburg (KUNDE)). 

Die Abfrage „Finde alle Kunden, die einen Kredit besitzen, und gebe 
jeweils den Kundennamen, dessen Stadt sowie die Kreditsumme aus“ kann 
durch eine Verknüpfung mehrerer Basisoperationen beantwortet werden: 

1. Verknüpfung der Relationen KUNDE und KREDIT über ein kartesisches Pro- 
dukt: KUNDE X KREDIT 

2. Selektion solcher Verknüpfungen, bei denen KName übereinstimmt: 

Selektion[<uNDE.KName=KREDIT. KName (KUNDE X KREDIT) 

3. Projektion der Attribute KName, KStadt und Betrag: 

ProjektionKUNDE. KName, KUNDE.KStadt, KREDIT. Betrag 
(SelektionKUNDE.KName=KREDIT. KName (KUNDE X KREDIT)) 

Hierbei wird die Kombination der ersten beiden Schritte (Bilden des karte- 
sischen Produktes und Selektion bezüglich der Identität korrespondierender 
Attribute) als Join bezeichnet. 

® Die in Abschnitt 5.4 behandelte relationale Datenbanksprache SQL basiert anf 
der Relationenalgebra (d. h. in SQL existieren den Operationen entsprechende 
Befehle) . 

Hierbei vereinfachen wir leicht hinsichtlich der Vernachlässigung der Problematik 
der (eindentigen) Benennung von Attributen. 
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5.3.1 Normalisierung 

Es gibt verschiedene Möglichkeiten, eine zweckmäßige relationale Daten- 
bankstruktur (Tabellen, Attribute) für ein Anwendungsfeld zu entwerfen. 
Zum einen kann ausgehend von allen ermittelten Attributen (die innerhalb ei- 
ner einzigen Relation, der so genannten Universalrelation enthalten sind) eine 
Normalisierungsprozedur angewendet werden, mittels derer Tabellen erzeugt 
werden, die gewissen Bedingungen genügen. Andererseits kann eine Transfor- 
mation bereits sinnvoll strukturierter Entity-Relationship-Modelle erfolgen; 
vgl. Abschnitt 5.3.2. Primäres Ziel ist es jeweils, Daten weitgehend nicht- 
redundant darzustellen bzw. gewisse Abhängigkeiten zu reduzieren, um ins- 
besondere Datenänderungen (Update-Operationen) zu vereinfachen. 

Die Normalisierung soll wiederum am Beispiel eines Kreditinstitutes 
erläutert werden. Dabei ist von folgenden Gegebenheiten auszugehen: 

• Zu jedem Konto müssen Name, Straße und Stadt des Kunden sowie Kon- 
tonummer, Saldo und die Filiale gespeichert werden. 

• Zu jedem Kredit müssen Name, Straße und Stadt des Kunden sowie Kre- 
ditnummer, Kreditbetrag und die Filiale gespeichert werden. 

• Jede Filiale soll durch den Ort und eine Nummer identifiziert werden. 

Die Universalrelation, die alle Attribute beinhaltet, kann aus diesen Gege- 
benheiten (und den vorhandenen Daten, d. h. konkreten Ausprägungen der 
Attribute) ermittelt werden und ist in Tabelle 5.2 dargestellt. 



Name 


Straße 


Stadt 


Kto# 


Saldo 


Fil# 


FilOrt 


Kredit# 


Betrag 


Fil# 


FilOrt 


Voß 


Abtweg 


Potsdam 


9644 


193,69 


1 


City 


1737 


1811,40 


1 


City 








9611 


128,70 


1 


City 










Fink 


Barstr. 


Hamburg 










1662 


1011,67 


2 


Forum 



Tabelle 5.2. Tabelle der Universalrelation KREDITINSTITUT 



Das Hauptproblem einer solchen Universalrelation besteht darin, dass kei- 
ne Homogenität gegeben ist, da in einigen Zellen mehrere Einträge vorhanden 
sein können (d.h. einige Attribute können mehrere Ausprägungen besitzen). 
Um diesen Missstand zu beseitigen, wird die Universalrelation in die 1. Nor- 
malform überführt. 

Erste Normalform: Eine Relation ist in der 1. Normalform, wenn 
sie nur aus atomaren Attributen besteht, d. h. nur Attribute mit ein- 
facher Datenausprägung besitzt. 

Die Darstellung aus Tabelle 5.2 ändert sich bei einer Überführung in die 
1. Normalform entsprechend der Struktur in Tabelle 5.3. Bei dieser Darstel- 
lung entsteht jedoch das Problem, dass viele redundante Daten auftreten. 
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d.h. gleiche Datenausprägungen sind mehrfach gespeichert. Dies kann ins- 
besondere Probleme bei Datenänderungen bereiten, z.B. müssen bei einem 
Umzug eines Kunden, der mehrere Konten oder Kredite besitzt, dessen Stra- 
ße und Stadt mehrfach geändert werden. Hier hilft eine Transformation in 
die 2. Normalform. 



Name 


Straße 


Stadt 


Kto# 


Saldo 


Fil# 


FilOrt 


Kredit# 


Betrag 


Fil# 


FilOrt 


Voß 


Abtweg 


Potsdam 


9644 


193,69 


1 


City 


1737 


1811,40 


1 


City 


Voß 


Abtweg 


Potsdam 


9611 


128,70 


1 


City 


— 


— 


— 


— 


Fink 


Barstr. 


Hamburg 


— 


— 


— 


— 


1662 


1011,67 


2 


Forum 



Tabelle 5.3. Tabelle der 1. Normalform der Relation KREDITINSTITUT 



Zweite Normalform: Eine Relation ist in der 2. Normalform, 
wenn sie in der 1. Normalform ist und alle Attribute voll funktional 
von allen Schlüsseln abhängen, d. h. jedes (Nichtschlüssel-)Attribut 
benötigt alle Schlüssel zur Identifikation. 

Die Transformation von der 1. in die 2. Normalform erfolgt durch das 
Aufsplitten der Tabelle in mehrere Tabellen, wie Tabelle 5.4 am Beispiel ver- 
deutlicht. Jedoch kann auch diese Darstellung Anomalien nach sich ziehen, da 
transitive Abhängigkeiten existieren. Wenn z. B. der Kredit Nr. 1662 gelöscht 
wird, werden auch die Daten der Filiale 2 (nämlich die Ortsangabe „Forum“) 
gelöscht. 



Name 


Straße 


Stadt 




Kto# 


Name 


Saldo 


Fil# 


FilOrt 


Voß 


Abtweg 


Potsdam 




9644 


Voß 


193,69 


1 


City 


Fink 


Barstr. 


Hamburg 




9611 


Voß 


128,70 


1 


City 



Kredit# 


Name 


Betrag 


Fil# 


FilOrt 


1737 


Voß 


1811,40 


1 


City 


1662 


Fink 


1011,67 


2 


Forum 



Tabelle 5.4. Tabellen der 2. Normalform der Relation KREDITINSTITUT 
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Dritte Normalform: Eine Relation ist in der 3. Normalform, wenn 
sie in der 2. Normalform ist und keine transitiven Abhängigkeiten 
existieren. 

Bei der Transformation in die 3. Normalform werden die abhängigen Rela- 
tionen (in unserem Beispiel die Filiale) aus den Tabellen herausgetrennt und 
in eine neue Tabelle übernommen. Das Ergebnis der Transformation unseres 
Beispieles zur 3. Normalform zeigt Tabelle 5.5. 



Name 


Straße 


Stadt 




Kto# 


Name 


Saldo 


Eil# 


Voß 


Abtweg 


Potsdam 




9644 


Voß 


193,69 


1 


Fink 


Barstr. 


Hamburg 




9611 


Voß 


128,70 


1 



Kredit# 


Name 


Betrag 


Eil# 




1737 


Voß 


1811,40 


1 


1662 


Fink 


1011,67 


2 



Eil# 


FilOrt 


1 


City 



Forum 



Tabelle 5.5. Tabellen der 3. Normalform der Relation KREDITINSTITUT 



Es gibt weitere (weniger gebräuchliche) Normalformen, die zu einer fort- 
schreitenden Zerlegung der Daten in elementare Relationen führen, was spe- 
zielle Anomalien bei Anderungsoperationen verhindern kann. Andererseits 
ergibt sich hierdurch bei Abfragen in der Regel ein größerer Aufwand, da 
Daten aus zunehmend mehr Tabellen integriert werden müssen. 

5.3.2 Transformation von Entity-Relationship-Modellen 

Eine weitere Möglichkeit zum Entwurf einer relationalen Tabellenstruktur 
besteht in der Transformation eines (bereits stark strukturierten) Entity- 
Relationship-Modells (vgl. Abschnitt 4.2.1) in Tabellendefinitionen. Bei einer 
solchen Überführung kann nach folgendem Schema vorgegangen werden: 

1. Jeder Entitytyp wird in eine Tabelle (Relation) transformiert. 

2. Ein 1 : 1-Beziehungstyp wird durch Aufnahme eines (Fremd-) Schlüssels in 
eine der beiden Tabellen abgebildet. 

3. Ein l:n-Beziehungstyp wird durch Aufnahme des Schlüssels des Entity- 
typs, der in der Beziehung n-mal auftreten kann, in die dem anderen 
Entitytyp entsprechende Tabelle abgebildet.® 

® Im Beispiel des Beziehungstyps LESER-Ausleihe-BUCH kann ein Leser mehrere 
Bücher ausleihen, d. h. mehrmals in der Beziehung auftreten, so dass der Schlüssel 
des Lesers in die Tabelle BUCH aufgenommen werden muss. 
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4. Ein m:n-Beziehungstyp wird durch die Definition einer zusätzlichen Ta- 
belle, in der die Schlüssel aller beteiligten Entitytypen enthalten sind, 
abgebildet. 

5. Bei attributierten Beziehungen werden die Attribute des Beziehungstyps 
in die Tabelle, in der die Beziehung abgebildet ist, aufgenommen. 

Dieses Vorgehen ist jedoch nur für binäre Beziehungen möglich, da die in Ab- 
schnitt 4.2.1 beschriebene und diesen Regeln zu Grunde liegende Kardinalität 
nicht für höherwertige Beziehungen definiert ist. Höherwertige Beziehungen 
können jedoch analog in eine Tabellenstruktur überführt werden: 

6. Ein Beziehungstyp höheren Grades, bei dem (mindestens) ein Entitytyp 
eine Komplexität (min,max) mit max < 1 besitzt, wird durch Aufnahme 
des Schlüssels dieses Entitytyps in die den anderen Entitytypen entspre- 
chenden Tabellen abgebildet.® 

7. Ein Beziehungstyp höheren Grades, bei der jeder Entitytyp eine Kom- 
plexität (min, max) mit max = * besitzt, wird durch die Definition einer 
zusätzlichen Tabelle, in der die Schlüssel aller beteiligten Entitytypen 
enthalten sind, abgebildet. 

Zur Veranschaulichung greifen wir wiederum auf das (vereinfachte) Bei- 
spiel einer Bibliothek zurück. In Abbildung 4.10 auf S. 110 sind bereits drei 
Beziehungstypen zwischen den Objekttypen Leser, Buch und Magnetkarte 
definiert worden. Wenn man diese Beziehungstypen zusammenführt und (we- 
sentliche) Attribute hinzufügt, ergibt sich das ER-Modell in Abbildung 5.3. 

Bei der Transformation dieses ER-Modells in die Tabellenstruktur einer 
relationalen Datenbank wird in einem ersten Schritt für jeden Entitytyp eine 
Tabelle angelegt. Diese Tabellen müssen alle Attribute des jeweiligen Entity- 
typs enthalten: 

LESER (Name, Leser-Nr , . . .) 

BUCH ( Inv-Nr , Autor, Titel, ...) 

MAGNETKARTE ( Karten-Nr , . . .) 

Die Punkte in den Tabellen sollen andeuten, dass weitere Attribute (und 
somit weitere Spalten in den Tabellen) möglich sind (je nachdem, wie genau 
das ER-Modell die Realität abbildet). Nach dieser Transformation besitzen 
alle Tabellen einen Schlüssel. 

Im nächsten Schritt werden die l:l-Beziehungen, d. h. in unserem Beispiel 
der Beziehungstyp besitzt, in die vorhandenen Tabellen integriert. Hierbei 
muss man sich zuerst entscheiden, ob man das Attribut Leser-Nr in die 
Tabelle MAGNETKARTE oder die Nummer der Magnetkarte in die Tabelle LESER 
aufnehmen möchte. Da der Leser noch an weiteren Beziehungstypen beteiligt 

® Diese Regel kann auch bei einer IS-A-Beziehung angewendet werden, indem der 
Schlüssel des allgemeinen Entitytyps in die Tabellen der spezialisierten Entity- 
typen aufgenommen wird. 
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ist, entscheiden wir uns für Letzteres. Dadurch sind z. B. bei einer späteren 
Abfrage nach den Büchern, die auf eine bestimmte Magnetkartennummer 
ausgeliehen sind, weniger Verknüpfungen zwischen verschiedenen Tabellen 
notwendig, was Antwortzeiten verkürzen kann. Demnach ändert sich nur die 
Tabelle LESER: 

LESER (Name, Leser-Nr , Karten-Nr, ...) 

BUCH ( Inv-Nr , Autor, Titel, ...) 

MAGNETKARTE ( Karten-Nr , ...) 

Anschließend erfolgt die Transformation der l:n-Beziehung Ausleihe. 
Wichtig ist hierbei, dass neben dem (dann auch als Fremdschlüssel bezeichne- 
ten) Schlüssel Leser-Nr der Tabelle LESER auch das Attribut Rückgabedatum 
des Beziehungstyps der Tabelle BUCH hinzugefügt wird: 

LESER (Name, Leser-Nr , Karten-Nr, ...) 

BUCH ( Inv-Nr , Autor, Titel, Leser-Nr, Rückgabedatum, . . .) 

MAGNETKARTE ( Karten-Nr , ...) 

Die Transformation der m:n-Beziehung Bestellung des ER-Modells 
der Bibliothek führt zu einer zusätzlichen Tabelle, deren Spalten den 
Schlüsseln der an dem Beziehungstyp beteiligten Entitytypen und dem At- 
tribut Bestelldatum entsprechen. In dieser neuen Tabelle ist die eindeuti- 
ge Identifikation einzelner Zeilen nur durch die Kombination aller (Fremd-) 
Schlüssel möglich. Am Ende einer vollständigen Transformation des ER- 
Modells aus Abbildung 5.3 in eine relationale Datenbankstruktur stehen so- 
mit vier Tabellen: 
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LESER (Name, Leser-Nr , Karten-Nr, ...) 

BUCH ( Inv-Nr , Autor, Titel, Leser-Nr, Rückgabedatum, ...) 

MAGNETKARTE ( Karten-Nr , . . .) 

BESTELLUNG ( Leser-Nr , Inv-Nr , Bestelldatum) 



Zur weiteren Veranschaulichung transformieren wir das komplexere ER- 
Modell der Fluggesellschaft aus Abbildung 4.17 auf S. 115 (bzw. das umfang- 
reichere ER-Modell aus der Lösung zur Übungsaufgabe 1 aus Abschnitt 4.8.2; 
vgl. S. 280) in die Tabellenstruktur einer relationalen Datenbank. Zuerst wird 
für jeden Entitytyp eine Tabelle angelegt, die alle Attribute des Typs enthält. 
Demzufolge ergeben sich folgende Tabellen: 



PERSON 

ANGESTELLTER 

PASSAGIER 

TECHNIKER 

PILOT 

ABFLUG 

FLUG 

FLUGZEUG 

FLUGZEUGTYP 

WARTUNG 



(Ncune, Geburtsdatum, Pers-Nr , Adresse, . . .) 
(Beruf, Aufgaben, Ang-Nr, . . .) 
(Nationalität, . . .) 

(Team-Nr , . . .) 

(Lizenz, Stunden, ...) 

( Datum , Zeit , . . .) 

(Flug-Nr, Start, Ziel, ...) 

(Flugzeug-Nr , Nächste-Wartung, . . .) 

(Typ, Bezeichnung, Anzahl-Plätze, . . .) 
(Wartungs-Nr , von, bis, . . .) 



Es ist zu beachten, dass in diesem Beispiel aufgrund der enthaltenen IS-A- 
Beziehungen und der identifikatorischen Abhängigkeit bisher nicht alle Ta- 
bellen über einen Schlüssel verfügen. Deshalb ist eine entsprechende Über- 
tragung der Schlüsselattribute der übergeordneten Entitytypen erforderlich: 



PERSON 

ANGESTELLTER 

PASSAGIER 

TECHNIKER 

PILOT 

ABFLUG 

FLUG 

FLUGZEUG 

FLUGZEUGTYP 

WARTUNG 



(Name, Geburtsdatum, Pers-Nr , Adresse, . . .) 
(Beruf, Aufgaben, Ang-Nr, Pers-Nr, . . .) 
(Nationalität, Pers-Nr , . . .) 

(Team-Nr, Ang-Nr, ...) 

(Lizenz, Stunden, Ang-Nr, . . .) 

( Datum , Zeit, Flug-Nr, ...) 

(Flug-Nr, Start, Ziel, ...) 

(Flugzeug-Nr, Nächste-Wartung, . . .) 

(Typ, Bezeichnung, Anzahl-Plätze, . . .) 
(Wartungs-Nr, von, bis, ...) 



Nach dieser Transformation müssen alle Tabellen einen Schlüssel besitzen. Da 
dies der Fall ist (und damit alle Entitytypen einen Schlüssel besitzen), kann 
jetzt die Transformation der anderen Beziehungen vorgenommen werden. 
I:l-Beziehungen sind in diesem ER-Modell nicht vorhanden. Als Nächstes 
erfolgt die Transformation der l:n-Beziehungen (PILOT-f liegt-ABFLUG, 
FLUGZEUG-Exemplar-von-FLUGZEUGTYP, WARTUNG-von-FLUGZEUG und 
ABFLUG-mit-FLUGZEUG). Dies führt zu folgenden Veränderungen der 
Tabellen: 
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PERSON 


(Name, Geburtsdatum, Pers-Nr, Adresse, . . .) 


ANGESTELLTER 


(Beruf, Aufgaben, Ang-Nr, Pers-Nr, . 


..) 


PASSAGIER 


(Nationalität, Pers-Nr, . . .) 




TECHNIKER 


(Team-Nr, Ang-Nr, . . .) 




PILOT 


(Lizenz, Stunden, Ang-Nr, ...) 




ABFLUG 


(Datum, Zeit, FIug-Nr, FIugzeug-Nr, 


Ang-Nr 


FLUG 


(FIug-Nr, Start, Ziel, . . .) 




FLUGZEUG 


(FIugzeug-Nr , Nächste-Wartung, Typ, 


...) 


FLUGZEUGTYP 


(Typ, Bezeichnung, Anzahl-Plätze, .. 


.) 


WARTUNG 


(Wartungs-Nr, von, bis, FIugzeug-Nr, 


, ...) 



...) 



Die Transformation der vier m:n-Beziehungen des ER-Modells der Fluggesell- 
schaft führt zu folgenden zusätzlichen Tabellen, die als Spalten die Schlüssel 
der an der jeweiligen Beziehung beteiligten Entitytypen besitzen: 



KANN-WARTEN (Ang-Nr, Typ) 

KANN-FLIEGEN (Ang-Nr, T^) 

BUCHT ( Pers-Nr , Flug-Nr, Datum ) 

FUEHRT-DURCH (Ang-Nr, Wartungs-Nr) 

Auch hier ist die eindeutige Identifikation einzelner Zeilen der Tabellen jeweils 
nur durch die Kombination mehrerer Einträge möglich. Der Beziehungstyp 
BUCHT benötigt sogar drei Schlüsselattribute, da einer der an der Beziehung 
beteiligten Entitytypen (nämlich ABFLUG) zwei Schlüsselattribute besitzt, die 
beide in die Tabelle BUCHT übernommen werden müssen. 



5.4 Structured Query Language (SQL) 

Die Structured Query Language (SQL) ist die bedeutendste relationale Da- 
tenbanksprache. Sie wurde von ANSI genormt und somit zum Standard er- 
hoben.^ 

Die Datenbanksprache SQL vereint drei wesentliche Funktionsbereiche, 
die im Weiteren kurz dargestellt werden:® 

• Datendefinition 

• Datenmanipulation 

• Datenabfrage 

Bei der nachfolgenden Beschreibung von SQL-Befehlen verwenden wir fol- 
gendes Muster: 

^ Es existieren jedoch verschiedene SQL- Versionen. Außerdem unterscheiden sich 
die in der Praxis gebräuchlichen Datenbankmanagementsysteme in dem Ausmaß 
der Unterstützung der verschiedenen Sprachkonstrukte. 

® Weiterhin gibt es noch Konstrukte zur Definition von Zugriffsberechtigungen, 
auf die in diesem Buch nicht eingegangen wird. 
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• Jeder Befehl beginnt mit seiner Bezeichnung, die (wie alle anderen festste- 
henden Begriffe innerhalb eines Befehles) KURSIV dargestellt ist. 

• Bezeichnungen von Tabellen und Attributen erfolgen in Schreibmaschi- 
nenschrift, wobei für die Namen von Tabellen nur Großbuchstaben ge- 
nutzt werden. 

• Sonstige Befehlsteile (z.B. konkrete Werte für Attribute) sind in normaler 
Schrift gesetzt. 

• Runde Klammern schließen Parameter eines Befehles ein. 

• Optionale Teile eines Befehles stehen in eckigen Klammern. 



5.4.1 Datendefinition 



Im Rahmen der Datendefinition wird die Struktur von Relationen bzw. Ta- 
bellen festgelegt. Wichtige Operationen (Klauseln) sind das Erzeugen von 
Tabellen und Indextabellen, deren Löschung sowie die Änderung der Struk- 
tur von Tabellen. 

Erzeugung von Tabellen: Das Erzeugen von Tabellen geschieht mit 
dem folgenden Befehl (der hier verkürzt wiedergegeben ist): 

CREATE TABUE T 

( Spaltendefinition [, Spaltendefinition] . . . 

[, PRIMARY KEY (Spaltenname)] ); 

Die Spaltendefinition hat für jede Spalte die Struktur „Spaltenname Daten- 
typ [NOT NULLY . Der Datentyp bestimmt den Wertebereich der Einträge 
einer Spalte. Durch die Angabe NOT NULL wird festgelegt, dass in der ent- 
sprechenden Spalte in jeder Zeile ein Eintrag existieren muss. 

Betrachten wir wiederum das Beispiel des Kreditinstitutes. Die Tabelle 
KONTO kann in SQL folgendermaßen erzeugt werden; vgl. Tabelle 5.6. 



CREATE TABUE KONTO 
( Kto# INTEGER 
KName CHAR(20) 

Saldo DECIMAL(12,2) 
Filiale INTEGER 
PRIMARY KEY (Kto#)); 



NOT NULL, 
NOT NULL, 
NOT NULL, 
NOT NULL, 



Kto# 


KName 


Saldo 


Filiale 


Tabe 


Ile 5.6. 


Tabelle 


KONTO 



Hierbei werden zu den einzelnen Attributen Wertebereiche fest gelegt: In der 
Spalte KName ist die Anzahl der Zeichen in einer Zelle auf 20 beschränkt, in 
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den Spalten Kto# und Filiale sind nur ganze Zahlen zulässig und in der 
Spalte Saldo sind Dezimalzahlen mit 12 Stellen (davon zwei Nachkomma- 
stellen) erlaubt. Durch PRIMARY KEY wird der Schlüssel festgelegt, dessen 
Felder unbedingt als NOT NULL definiert sein müssen. 

Erzeugung von Indextabellen: Indextabellen dienen der Beschleuni- 
gung bestimmter Zugriffe auf Tabellen. Hierzu enthalten Indextabellen ge- 
wisse Felder einer anderen Tabelle in einer festzulegenden Reihenfolge mit 
Verweisen auf die jeweils korrespondierende Zeile der zugehörigen Tabelle. 
Aus einer Indextabelle leitet das DBMS bei Abfragen ab, in welcher Zeile 
der Ausgangstabelle das gesuchte Feld liegt. Auf diese Weise ist ein schnel- 
ler Zugriff auf einzelne Einträge möglich. Der Befehl zur Erzeugung einer 
Indextabelle lautet: 

CREATE fUNLQUE] LNDEX Indexname ON Tabellenname 
(Spalte [Sortierung] [, Spalte [Sortierung]] ...); 

Die optionale Angabe UNLQUE legt fest, dass der Index eindeutig sein muss, 
d. h. keine Duplikate erlaubt sind. Dies ist zur Wahrung der Einmaligkeit von 
Schlüsseln notwendig. Für die Tabelle KONTO (vgl. Tabelle 5.6) erzeugt der 
Befehl 

CREATE UNLQUE LNDEX INDEXKONTO ON KONTO (Kto# ASC); 

eine Indextabelle INDEXKONTO, in der die Zellen der Spalte Kto# aufsteigend 
sortiert sind. Neben der Sortierung ASC (aufsteigend) ist noch DESC 
(absteigend) möglich. 

Löschung von Tabellen oder Indextabellen: Um eine Tabelle (oder 
Indextabelle) zu löschen, verwendet man den Befehl 

DROP TABLE Tabellenname; 

Der Tabellenname T kann hierbei auch der Name einer Indextabelle sein. Die 
im vorigen Absatz erzeugte Indextabelle wird folglich mit dem Befehl 

DROP TABLE INDEXKONTO; 

gelöscht. 

Änderung von Tabellen: Das Hinzufügen einer Spalte zu einer Tabelle 
T erfolgt mit dem Befehl 

ALTER TABLE T ADD (Spaltenname Datentyp [NOT NULL]); 

Soll in die Beispieltabelle KONTO eine Spalte Datum (der Eröffnung des Kontos) 
hinzugefügt werden, so geschieht dies mittels 

ALTER TABLE KONTO ADD (Datum DATE); 
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Die Änderung des Datentyps einer Spalte einer Tabelle T ist durch 

ALTER TABLE T MODIEY (Spaltenname Datentyp [NOT NULL]) 

möglich. Eine Vergrößerung der zulässigen Länge von KNarnie in unserem Bei- 
spiel erfolgt demnach über den Befehl 

ALTER TABLE KONTO 

MODLFY (KName CHAR(35) NOT NULL). 



5.4.2 Datenmanipulation 

Im Rahmen der Datenmanipulation erfolgt die Erzeugung und Änderung von 
Äusprägungen von Relationen, d. h. von Tabelleneinträgen (ganzen Zeilen 
bzw. Teilen davon). Wichtige Klauseln sind die Einfügung und Löschung 
von Zeilen sowie die Änderung von einzelnen Zeileneinträgen. 

Einfügung von Zeilen: Um eine Zeile in eine Tabelle T einzufügen, 
verwendet man den Befehl 

INSERT INTO T VALUES (Spalteneintrag [, Spalteneintrag] ...); 

Der Befehl 

INSERT INTO KONTO VALUES (9644, "Voß", 193.69, 1); 

entspricht einer Kontoeröffnung des Kontos mit der Nummer 9644 für 
den Kunden „Voß“ mit einer Einzahlung von 193,69 € in Filiale 1. Hierbei 
ist auf die richtige Reihenfolge und die Wertebereiche der Ättribute zu achten. 

Löschung von Zeilen: Das Löschen von Zeilen erfolgt in SQL mit 
DELETE EROM T [WHERE Pj; 

wobei genau die Zeilen aus Tabelle T gelöscht werden, die die Bedingung P 
erfüllen. Falls keine Bedingung angegeben ist, werden alle Zeilen gelöscht. 
Wenn in unserem Beispiel die Filiale 1 aufgelöst wird und dabei alle Konten 
dieser Filiale gelöscht werden sollen, wird dies mit folgendem Befehl erreicht: 

DELETE EROM KONTO WHERE Filiale = 1. 

Änderung von Zelleneinträgen: Die Äusprägung von Zellen in einer 
Tabelle T kann durch 



UPDATE T SET Spaltenname = newvalue [WHERE Pj; 
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geändert werden. Hierdurch werden genau diejenigen Einträge in der Spalte 
Spaltennamie auf den neuen Wert „newvalue“ gesetzt, deren Zeilen der Be- 
dingung P genügen. Als Beispiel sei angenommen, dass das Kreditinstitut 
an einem bestimmten Tag eine Sondergratifikation herausgibt, wobei Konten 
mit einem Saldo von mindestens 10000 € einen Zuschlag von 5% erhalten und 
Konten mit einem kleineren Guthaben 4%. Die Änderung der entsprechenden 
Salden kann über die Ausführung der folgenden beiden Befehle erfolgen: 

UPDATE KONTO SET Saldo = Saldo*1.05 
WHERE Saldo >= 10000; 

UPDATE KONTO SET Saldo = Saldo*1.04 
WHERE Saldo < 10000 AND Saldo > 0; 

In diesem Fall ist die Reihenfolge der beiden Updates entscheidend. Bei ei- 
ner Vertauschung der Befehle erhielten Konten mit einem Guthaben von z. B. 
9900 € beim ersten Update eine Erhöhung des Saldos um 4% ( 396 €), so dass 
der Saldo nach dieser Änderung 10296 € betrüge. Anschließend wäre dann 
jedoch auch die Bedingung für den zweiten Update-Befehl erfüllt, so dass eine 
nochmalige Erhöhung des Saldos auf nunmehr 10810,80 € (= 10296 € • 1,05) 
erfolgte, was einem Zuschlag von insgesamt 9,2% anstelle der vorgesehenen 
4% entspräche. 



5.4.3 Datenabfrage 

Im Rahmen einer Datenabfrage {Query) erfolgt die Ermittlung bestimm- 
ter Daten auf Basis einer vorgegebenen Tabellenstruktur und entsprechender 
Ausprägungen dieser Tabellen. Die Basisstruktur einer SQL-Abfrage besteht 
aus drei Klauseln, die den auf S. 157 vorgestellten Basisoperationen von Da- 
tenbanken entsprechen: 

• SELECT 

zur Ausgabe der gesuchten Attribute, d.h. der Spaltenauswahl aus einer 
Tabelle (Projektion), 

• EROM 

zum Beschreiben der Tabellen, in denen gesucht werden soll; bei mehreren 
Tabellen werden diese mittels des kartesischen Produktes verknüpft, 

• WHERE 

zur Definition von Bedingungen, unter denen gesucht wird, d. h. der Zei- 
lenauswahl aus einer Tabelle (Selektion). 

Diese Klauseln werden verwendet, um eine SQL-Abfrage zu formulieren, die 
folgende Grundstruktur besitzen muss: 

SELECT [DISTINCT] Ai, Aa, . . ., A„ 

EROM Ti, Ta, . . ., T„ 

[WHERE P] 
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[UNION/ EXCEPT/INTERSECT andere SELECT-Kla.nsel] 

[ORDER BY Spalte]; 

Die Angabe von Bedingungen P (unter möglicher Verwendung von logischen 
Operatoren wie AND, OR und NOT), eine Kombination mehrerer Abfra- 
gen (mittels der Befehle UNION, EXCEPT bzw. INTERSECT) sowie eine 
Sortierung der auszugebenden Zeilen nach bestimmten Spalteneinträgen (mit 
ORDER BY) ist möglich, aber nicht unbedingt erforderlich. Wenn keine Be- 
dingung P angegeben ist, werden alle Zeilen ausgegeben. Die ebenfalls optio- 
nale Angabe von DISTINCT verhindert die mehrfache Ausgabe identischer 
Zeilen der Ergebnisrelation (was der eigentlichen mengenorientierten Sicht 
auf Relationen entspricht). 

Zur beispielhaften Verdeutlichung der Formulierung von Abfragen ver- 
wenden wir wiederum das Beispiel des Kreditinstitutes mit den drei Tabellen 
KONTO, KUNDE und KREDIT: 

KONTO (Kto#, KName, Saldo, Filiale) 

KUNDE (KName, KStrasse, KStadt) 

KREDIT (Kredit#, KName, Betrag, Filiale) 

Alle Städte, in denen Kunden wohnen, können durch 

SELECT DISTINCT KStadt FROM KUNDE; 

ermittelt werden. Zum Auffinden der Namen aller Kunden, die in Hamburg 
wohnen, lautet die SQL-Abfrage 

SELECT KName FROM KUNDE WHERE KStadt = ” Hamburg”; 

Sind der Name, die Straße und der Kreditbetrag aller Kunden, die einen 
Kredit haben, gesucht, dann kann man formulieren: 

SELECT KUNDE. KName, KUNDE. KStrasse, KREDIT. Betrag 
FROM KREDIT, KUNDE 
WHERE KREDIT. KName = KUNDE. KName; 

Die letzte Abfrage ist ein Beispiel für einen so genannten Join. Hierbei werden 
alle Tupel von Tabellen verknüpft, bei denen eine entsprechende Übereinstim- 
mung bestimmter Attributwerte vorliegt. 

Die Namen aller Kunden von Filiale 1 werden über die Abfrage 

SELECT DISTINCT KName FROM KONTO 
WHERE Filiale = 1 ORDER BY KName; 

ermittelt und dabei alphabetisch sortiert. 

Über die oben angegebene Grundstruktur von SQL- Abfragen hinaus exis- 
tieren einige weitergehende nützliche Abfragemöglichkeiten, was sich u. a. auf 
Rechenoperationen über die Zeilen von (Ergebnis-)Relationen erstreckt. Die 
Bestimmung der Anzahl aller Konten von Filiale 1 kann z. B. folgendermaßen 
erfolgen: 




170 



5. Datenbanken 



SELECT COUNT (Kto#) FROM KONTO WHERE Filiale = 1; 

Analog zur Ermittlung einer Anzahl {COUNT) ist auch die Berechnung der 
Summe (SUM), des Durchschnittes (AEG), des Maximums {MAX) und des 
Minimums {MIN) von Spaltenwerten möglich (z. B. die Summe aller Kredit- 
beträge). 

Die Ermittlung der Namen aller Kunden, die ein Konto in Filiale 1 be- 
sitzen, aber keinen Kredit (in welcher Filiale auch immer) haben, kann auf 
verschiedenen Wegen erfolgen. Zum einen können zuerst alle Kunden gesucht 
werden, die ein Konto in Filiale 1 besitzen und von diesen Kunden all jene 
aus der Abfrage herausgenommen werden, die einen Kredit besitzen: 

{SELECT KName FROM KONTO WHERE Filiale = 1) 

EXCEPT {SELECT KName FROM KREDIT); 

Eine alternative Möglichkeit der Abfrage der Kunden von Filiale 1, die nicht 
in der Tabelle KREDIT aufgeführt sind, ergibt sich über eine Verschachtelung 
von SQL-Abfragen: 

SELECT KName FROM KONTO WHERE Filiale = 1 

AND KName NOT IN {SELECT KName FROM KREDIT); 

Neben NOT IN ist auch der umgekehrte Operator IN definiert. 

Außerdem kann man auch „Vergleiche“ eines einzelnen Wertes mit einer 
Menge von Werten (einer Spalte) durchführen, wobei ermittelt wird, ob die 
angegebene Relation für alle Kombinationen gilt {ALL) oder für mindestens 
eine Kombination des Einzelwertes mit einem Wert aus der Menge {ANY). 
Als Vergleichsrelationen können u. a. =, <, > und <> verwendet werden. 
So erhält man etwa die Namen der Kunden mit dem größten Saldo über die 
folgende Abfrage: 

SELECT KName FROM KONTO 

WHERE Saldo >= ALL {SELECT Saldo FROM KONTO); 

Das gleiche Ergebnis erhält man auch über die Anwendung des MAX- 
Operators: 

SELECT KName FROM KONTO 

WHERE Saldo = {SELECT MAX {Sa.ldo) FROM KONTO); 

Abschließend wird noch auf die Möglichkeit eines unscharfen Vergleiches 
mit (Teilen von) Zeichenketten hingewiesen. Hierzu verwendet man einen 
Operator LIKE sowie die Platzhalter (steht für eine beliebige Anzahl 
beliebiger Zeichen) und (steht für ein einzelnes beliebiges Zeichen). So 
ermittelt z. B. die folgende Abfrage alle Kundennamen, die mit dem Buch- 
staben „F“ beginnen: 

SELECT KName FROM KONTO WHERE KName LIKE ”F%”; 
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5.4.4 Sichten 

Sichten ( Views) sind Ergebnisse einer Abfrage, auf denen weitere Operatio- 
nen durchgeführt werden können. Entsprechende Relationen existieren in der 
Regel nicht physisch, sondern werden jeweils dynamisch erzeugt. Eine Sicht 
wird folgendermaßen als eine einer SQL- Abfrage entsprechende Relation de- 
finiert: 

CREATE VIEW V AS <SQL-Query>; 

Die Verwendung von Sichten ist beispielsweise dann sinnvoll, wenn unter- 
schiedliche Nutzergruppen auf spezielle Ausschnitte einer Datenbank zugrei- 
fen sollen. In unserem Beispiel des Kreditinstitutes werden die Daten aller 
Kunden und aller Filialen in einer Datenbank verwaltet. Es erscheint jedoch 
nicht unbedingt notwendig, dass jeder Sachbearbeiter in vollem Umfang Zu- 
griff auf diese Daten besitzt, sondern er sollte gegebenenfalls jeweils nur die 
Daten seiner eigenen Filiale nutzen können, nicht jedoch die Daten anderer 
Filialen. Um dies zu erreichen, werden verschiedene Sichten erstellt, die je- 
weils nur die Daten der Kunden einer Filiale umfassen. Auf einer derartigen 
Sicht kann der Sachbearbeiter dann Abfragen mit Hilfe der oben beschriebe- 
nen Abfrage-Befehle durchführen. 

Die Sicht, bei der die Angestellten von Filiale 1 nur die Namen, Adressen, 
Kontonummern, Saldi, Kreditnummern und Kreditbeträge der Kunden ihrer 
Filiale sehen können, wird z. B. folgendermaßen erstellt: 

CREATE VIEW KUNDEN-FILIALE-1 AS 

( 

SELECT KName, KStraße, KStadt, Kto#, Saldo, Kredit#, Betrag 

FROM KONTO, KUNDE, KREDIT 

WHERE 

(KONTO. Filiale = 1 AND KONTO. KName = KUNDE. KName) 

OR 

(KREDIT. Filiale = 1 AND KREDIT. KName = KUNDE. KName) 

); 



5.4.5 Optimierung von Datenbankabfragen 

Zur Ausführung müssen SQL-Abfragen in prozeduralen Code übersetzt wer- 
den. Da es hierzu in der Regel verschiedene Möglichkeiten gibt, ist eine Op- 
timierung sinnvoll. So kann z.B. die Kommutativität von Selektionen aus- 
genutzt werden, indem zuerst die Selektion, die die kleinere Zwischenrela- 
tion erzeugt, ausgeführt wird. Insbesondere bei der Verwendung von Joins 
ist eine Optimierung wichtig, da Joins (wegen des Bildens von kartesischen 
Produkten) sehr aufwändig sein können. Wenn also mehr als zwei Relationen 
durch einen Join miteinander verknüpft werden sollen, muss entschieden wer- 
den, in welcher Reihenfolge die Joins durchgeführt werden. Auch dies sollte 
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sinnvollerweise so geschehen, dass zuerst möglichst kleine Zwischenergebnisse 
erzeugt werden. 



5.5 Data-Warehouse-Konzept 

Mit dem Begriff Data Warehouse wird eine von den operativen Systemen 
getrennte Datenbank bezeichnet, die als unternehmensweite Datenbasis für 
Analysezwecke dient.® Im Rahmen der Transaktionsdatenverarbeitung, des 
so genannten Online Transaction Processing (OLTP), erfolgt die zeitna- 
he/direkte Abwicklung operativer Geschäftsvorfälle. Entsprechende Systeme 
bezeichnet man auch als Transaktionssysteme bzw. die entsprechenden Da- 
ten als operative Daten. In diesem Zusammenhang werden u. a. hohe Anfor- 
derungen an die Verarbeitungsgeschwindigkeit sowie die Verfügbarkeit und 
Aktualität der Daten gestellt. 

Dagegen ergeben sich bei entscheidungsunterstützenden Systemen, im 
Rahmen des so genannten Online Analytical Processing (OLAP), andere An- 
forderungen an den Datenbestand und -Zugriff. Die idealtypischen Funktionen 
der Datenbankkomponente von Analysesystemen lassen sich folgendermaßen 
zusammenfassen (vgl. Inmon (2002) sowie Koutsoukis et al. (1999)): 

• Daten sollten nicht primär anwendungsbezogen strukturiert werden, son- 
dern zu einem Thema (auf der Grundlage verschiedener Datenquellen) in- 
tegriert, normiert und systematisch gespeichert werden. 

• Daten sind im Zeitverlauf zu speichern. 

• Daten sind über einen längeren Zeitraum zu speichern. 

• Es ist ein Zugriff über eine einheitliche Schnittstelle auf die Daten zu 
ermöglichen. 

• Es sind verschiedene Sichten auf die Datenbestände zu realisieren. 

Das heißt, für Analysen werden typischerweise aggregierte bzw. verdich- 
tete Daten benötigt, die in den operativen Datenbeständen nicht unmittelbar 
vorhanden sind, sondern erst aus diesen erzeugt werden müssen (z.B. Quar- 
talsübersichten zu wichtigen betrieblichen Kennzahlen). Darüber hinaus sind 
oftmals historische Daten aus der weiter zurückliegenden Vergangenheit von 
Interesse (z. B. um auf deren Grundlage Prognosen über den zukünftigen 
Absatz von Produkten zu erstellen) . Der Datenzugriff bei Analysen ist dabei 
primär lesend. 

Insbesondere für komplexe Analysen ist ein direkter Zugriff auf die ope- 
rativen Daten aus Transaktionssystemen problematisch, da sich für entspre- 
chende Datenbankabfragen häufig ein relativ hoher (Zeit-)Aufwand ergibt 
(z.B. viele Joins, um verdichtete Daten zu erhalten). Dies würde gegebenen- 
falls zu einer Verringerung der Leistungsfähigkeit der Transaktionssysteme 

® Vgl. hierzu z.B. Chamoni und Gluchowski (1999), Inmon (2002) sowie ferner 
auch Dueck (1999). 
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führen bzw. den operativen Betrieb beeinträchtigen. Ein weiterer wichtiger 
Grund für die redundante Speicherung der für Analysen relevanten Daten be- 
steht darin, dass in vielen Unternehmen Transaktionssysteme (noch) teilweise 
in der Form von zweckbezogenen Insellösungen vorliegen bzw. kein integrier- 
ter Datenbestand existiert. Deshalb muss bereichsübergreifenden Analysen 
eine gegebenenfalls komplizierte Datenintegration vorausgehen. 

Demzufolge erscheint die Trennung der Datenhaltung für Analysezwecke 
von den operativen Daten in der Regel als sinnvoll. Aufgabe eines Data Ware- 
house ist damit eine effizienten Sammlung bzw. Bereitstellung aktueller und 
historischer, gegebenenfalls verdichteter und qualitativ hochwertiger Daten. 
Dabei stellt das Data Warehouse eine Art „Zwischenschicht“ zwischen den 
Transaktionssystemen auf der einen und den Analysesystemen auf der an- 
deren Seite und demzufolge eine Basis für entscheidungsunterstützende Sys- 
teme dar. Abbildung 5.4 veranschaulicht die entsprechende Strukturierung 
und Konsolidierung der Datenbestände als ein Ziel des Data-Warehouse- 
Konzeptes. 



Analysesysteme Analysesysteme 




Abbildung 5.4. Strukturierung der Datenhaltung - der Übergang zu einem Data 
Warehouse; Quelle: Voß und Gutenschwager (2001), S. 258 



5.6 Datenmanagement 

Die primäre Zielsetzung des Datenmanagements ist es, die Beschaffung und 
Bereitstellung verschiedenster Daten zur Aufgabenerfüllung und Entschei- 
dungsunterstützung zu gewährleisten. Datenmanagement umfasst folglich 
Prozesse im Zusammenhang mit der Planung, Beschaffung, Verwaltung und 
Nutzung der Unternehmensressource Daten; vgl. Dippold et al. (2001). Das 
Datenmanagement wurde in Kapitel 3 als ein wichtiger Aufgabenbereich 
auf der mittleren Ebene des Ebenenmodells des Informationsmanagements 
eingeordnet. Entsprechende Aufgaben beziehen sich sowohl auf die konzep- 
tionelle Ebene (z. B. Ableitung von Datenbedarfen und Entwicklung von 
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(Unternehmens-)Datenmodellen) wie auch die in diesem Kapitel behandel- 
ten Datenbanken. Weiterhin sind organisatorische Aspekte zu berücksichti- 
gen (Zuordnung von Verantwortlichkeiten, z.B. für die Pflege eines zentralen 
Datenkataloges (Data Dictionary)). 

Innerhalb des Datenmanagements beschäftigt man sich neben formatier- 
ten Datenbanken auch mit unformatierten Daten. Die in den bisherigen Ab- 
schnitten dieses Kapitels behandelten formatierten Datenbanken sind typi- 
scherweise dadurch charakterisiert, dass 

• eine Gruppierung und Klassifikation der Daten nach Maßgabe ihrer Homo- 
genität möglich ist, 

• ein gemeinsames Schema für die abgelegten Daten existiert, 

• die Daten durch ein relationales Datenbankmanagementsystem verwaltet 
werden, 

• eine Redundanzarmut angestrebt wird, 

• eine logische Verknüpfbarkeit der Daten über Abfragen relativ einfach 
möglich ist sowie 

• die Zeiten für Datenmanipulationen und -abfragen kurz sind (Effizienz). 

Auf Basis strukturierter Datenbanken, die auch entsprechende Data- 
Warehouse-Systeme einschließen, ist eine Informationsgewinnung prinzipiell 
für jeden (berechtigten) Nutzer möglich. Allerdings sind die Anforderungen 
im Zusammenhang mit der direkten Formulierung von Datenabfragen über 
Datenbankabfragesprachen (wie etwa SQL) aufgrund der Komplexität typi- 
scher Datenbankmodelle relativ hoch. Das heißt, eine nutzeradäquate Infor- 
mationsbereitstellung ist hiermit nicht unbedingt gewährleistet. Demzufolge 
ist häufig ein Einsatz spezieller OLAP-Systeme zweckmäßig, die auf Analy- 
sezwecke ausgerichtete Softwaresysteme mit relativ einfach bedienbarer gra- 
phischer Benutzeroberfläche darstellen. 

Es gibt auch Datenbestände, die diese Eigenschaften formatierter Daten- 
banken nicht besitzen. Derartige unformatierte Datenbestände sind z. B. Brie- 
fe und Präsentationen in speziellen Dateiformaten, aber auch multimediale 
Daten wie Graphiken und Videos. Solche Datenbestände sind in der Regel 
durch den Menschen im Einzelfall intuitiv verständlich, dagegen schwierig au- 
tomatisiert zu verarbeiten (bzw. zu ermitteln). Nichtsdestotrotz ist im Kon- 
text des Wissens- und Dokumentenmanagements (vgl. Abschnitt 3.3.2) eine 
explizite Speicherung und automatisierte Verarbeitung unformatierter Daten 
häufig anzustreben. Unformatierte Datenbestände zeichnen sich dadurch aus, 
dass 

• auf semantischer Ebene keine gemeinsamen Formate existieren, 

• kein Datenbankmanagementsystem existiert, das die Integrität über die 
gesamte Datenbank sichert, 

• keine formale Abfragesprache existiert (und die Suche z.B. über Textmus- 
ter erfolgen muss), 

• Datenbestände häufig extrem verteilt vorliegen sowie 
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• die Informationssuche in solchen Datenbeständen über so genannte 
Information-Retrie val-Methoden erfolgt . 

Neben den bisher betrachteten Daten in elektronischer Form liegen oft 
auch Daten beziehungsweise Informationen in nichtelektronischer Form vor, 
z. B. Akten, Organisationshandbücher und Verträge. Diese sind oftmals nicht 
aktuell, ihre Verteilung ist aufwändig und Zugriffsmöglichkeiten sind meist 
beschränkt oder sogar ungeklärt. In einem gewissen Maße kann das Scannen 
dieser Texte und eine anschließende automatische Zeichenerkennung (OCR, 
Optical Character Recognition) Abhilfe leisten, wobei sich die Frage stellt, für 
welche Dokumente dieses Vorgehen sinnvoll ist (auch vor dem Hintergrund 
des Aufwandes für die manuelle Korrektur der Ergebnisse). Außerdem sind 
hierdurch nur sehr eingeschränkt semantische Informationen zur Struktur der 
Daten gewinnbar. 



5.7 Übungen und Kontrollfragen 

1. Welchen Anforderungen sollte ein Datenbankmanagementsystem im 
Rahmen der Transaktionsverarbeitung genügen, um einen konsistenten 
Zustand der Daten zu gewährleisten? 

2. Erläutern Sie die drei Abstraktionsebenen von Datenbanken! 

3. Zu Aufgabe 2 aus Abschnitt 4.8.2: 

a) Transformieren Sie das erstellte ER-Modell in eine relationale 
D atenbankst ruktur ! 

b) Erstellen Sie eine SQL-Abfrage, die angibt, welcher Fahrer (Name) 
die Bestellung Nr. 13 zu welchem Kunden (Name und Adresse) 
ausliefern soll! Die Abfrage soll die in Klammern angegebenen 
Informationen liefern. 

4. Zu Aufgabe 3 aus Abschnitt 4.8.2: 

a) Transformieren Sie das erstellte ER-Modell in eine relationale 
D atenbankst ruktur ! 

b) Sie erfahren von einer Rückrufaktion des Herstellers Ihres Com- 
putersystemtyps mit der Typnummer 271. Demzufolge müssen Sie 
alle Studenten, die ein solches Computersystem bereits ausgeliehen 
haben, benachrichtigen. Erstellen Sie eine SQL-Abfrage, die Ihnen 
die Telefonnummern aller entsprechenden Studenten liefert! 
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5. Zu Aufgabe 4 aus Abschnitt 4.8.2: 

a) Transformieren Sie das erstellte ER-Modell in eine relationale 
D atenbankstruktur ! 

b) Erstellen Sie eine SQL-Abfrage, um die Information zu gewinnen, 
Maschinen welcher Maschinenproduzenten an Station 6 verwendet 
werden! 




6. Softwareentwicklung 



Wie bereits in Kapitel 1 verdeutlicht wurde, besteht eine wichtige Aufgabe der 
Wirtschaftsinformatik in der Entwicklung von (betrieblichen) Informations- 
und Kommunikationssystemen. Hierfür relevante Methoden der Softwareent- 
wicklung bilden eine wesentliche Grundlage der Wirtschaftsinformatik. Hier- 
bei ist zu konstatieren, dass sich entsprechende Tätigkeiten tendenziell weg 
von der reinen Neuentwicklung von Software hin zu einer Anpassung von 
Standardsoftware, Wiederverwendung bzw. Kombination von Softwarekom- 
ponenten sowie einer Integration von (Teil-)Systemen verlagern. 

Das Fachgebiet innerhalb der Informatik, das sich mit der Softwareent- 
wicklung beschäftigt, wird als Softwaretechnik oder Software Engineering be- 
zeichnet.^ Hierbei geht es um das so genannte „Programmieren im Großen“, 
bei dem aufgrund des Systemumfanges und der hierdurch in der Regel er- 
zwungenen Arbeitsteilung im Vergleich mit der isolierten Programmierung 
spezieller Algorithmen weitergehende Probleme auftreten. Informations- und 
Kommunikationssysteme in Wirtschaft und Verwaltung bilden typischerweise 
komplexe Systeme. Es hat sich gezeigt, dass die Entwicklung entsprechender 
Software eine ebenfalls komplexe Aufgabe darstellt. Im Zusammenhang mit 
der Beobachtung, dass Softwareprojekte in der Praxis oft nicht termingerecht, 
mit überhöhten Kosten oder qualitativ nicht zufrieden stellenden Resultaten 
abgeschlossen werden, wurde auch der Begriff Softwarekrise geprägt. 

Aufgrund der Komplexität der Entwicklung umfangreicher Softwaresys- 
teme ist eine Strukturierung und arbeitsteilige Organisation des Entwick- 
lungsprozesses erforderlich. Bevor in Abschnitt 6.2 entsprechende Vorgehens- 
modelle für die grundsätzliche Ablauforganisation diskutiert werden, werden 
im folgenden Abschnitt zunächst die eigentlichen Aktivitäten der Software- 
entwicklung erläutert (grob gliederbar in Analyse, Entwurf und Implemen- 
tierung mit der wichtigen Querschnittsfunktion Qualitätsmanagement). Die 
in einem gewissen Sinne meistens vorliegende Einmaligkeit einer konkreten 
Systementwicklung führt typischerweise zu einer Organisation des Entwick- 
lungsvorhabens als Projekt; in Abschnitt 6.3 werden entsprechende Aspekte 
des Softwareprojektmanagements behandelt. 

Für vertiefende Darstellungen zur Softwareentwicklung verweisen wir z. B. auf 

Balzert (2000, 1998) sowie Sommerville (2004). 
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Der im Vergleich zu klassischen Ingenieurwissenschaften anscheinend un- 
genügende Grad der Wiederverwendung bei der Softwareentwicklung wird 
häufig als das Kernproblem der Softwaretechnik betrachtet. Im abschließen- 
den Abschnitt 6.4 werden deshalb einige neuere Aspekte bzw. Techniken der 
Softwareentwicklung aus dem Blickwinkel des Zieles Softwarewiederverwen- 
dung betrachtet. Dies bezieht sich konkret auf die Objektorientierung, die 
Komponententechnik sowie das so genannte Domain Engineering. 



6.1 Aktivitäten der Softwareentwicklung 

Software unterliegt in der Regel einem typischen Lebenszyklus . Dieser umfasst 
die gesamte Lebensdauer einer Software von den ersten Ideen für ihre Kon- 
zeption bis zur Außerbetriebnahme bzw. Ablösung. Diese Lebensdauer kann 
in verschiedene Abschnitte unterteilt werden; vgl. Abbildung 6.1. Die ersten 
Abschnitte des Lebenszyklus (Planung bis Test) sind dabei der eigentlichen 
Softwareentwicklung zuzurechnen. Der Abschnitt Wartung und Pflege, der in 
den Zeitraum der Nutzung der Software fällt, kann als Bindeglied zwischen 
der Entwicklung von zwei aufeinander folgenden Softwaresystemen bzw. Ver- 
sionen eines solchen betrachtet werden. 




Abbildung 6.1. Softwarelebenszyklus 



Ausgehend vom Softwarelebenszyklus kann die Softwareentwicklung in 
einzelne Aufgabenbereiche (Phasen) zerlegt werden. Unter einer solchen Pha- 
se verstehen wir in Anlehnung an DIN 69901 einen zeitlichen Abschnitt der 
Softwareentwicklung, der sachlich von anderen Abschnitten getrennt abläuft. 
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Auf Basis des Softwarelebenszyklus ergeben sich die Aufgabenbereiche Pla- 
nung, Anforderungsanalyse, Entwurf, Implementierung, Test, Integration und 
Einführung sowie Wartung und Pflege; vgl. Tabelle 6.1. Darüber hinaus ist 
ein durchgängiges Qualitätsmanagement als wichtige Querschnittsfunktion 
zu betrachten, die alle Aufgabenbereiche betrifft. 



Aktivität 


Inhalt 


Ergebnis 


Planung 


Problemanalyse, Projektzielsetzung 


Produkt- 

beschreibung 

(Lastenheft) 


Anfordernngs- 

analyse 


detaillierte Beschreibung 
der Systemanforderungen 
(Funktionalität, Leistungsumfang) 


Anforderungs- 

spezifikation 

(Pflichtenheft) 


Entwurf 


Grobentwurf und Feinentwurf der 
Softwarearchitektur 


Entwurfs- 

spezifikation 


Implementierung 


Umsetzung des Entwurfes 


Software 


Test, Integration und 
Einführung 


Test des Systems, Integration der 
implementierten Module zu einem 
Gesamtsystem 


Dokumentation 


Wartung und 
Pflege 


Fehler korrektur, Anpassung an 
veränderte Anforderungen 


neue Version 



Tabelle 6.1. Typische Aufgabenbereiche der Softwareentwicklung 



Wie die Diskussion verschiedener Vorgehensmodelle in Abschnitt 6.2 zei- 
gen wird, werden diese Aufgabenbereiche, die in den folgenden Abschnitten 
näher beschrieben werden, bei einer hinreichend komplexen Entwicklungsauf- 
gabe typischerweise nicht einmalig auf Basis einer strengen Phasengliederung 
sequenziell durchlaufen werden können. Deshalb verwenden wir im Folgenden 
den Begriff der Aktivität (anstatt Phase). Nichtsdestotrotz korrespondiert die 
hier verwendete Reihenfolge der Beschreibung der Aktivitäten offensichtlich 
mit der natürlichen Reihenfolge in einem prinzipiellen Entwicklungsvorgang. 

6.1.1 Planung 

In der Planung werden auf Basis einer Problemanalyse die grundlegenden 
Anforderungen an ein Entwicklungsprojekt und eine hierauf basierende Grob- 
planung für die Umsetzung erarbeitet. Dem geht normalerweise eine Projekt- 
initiierung voraus, in deren Rahmen in einem so genannten Lastenheft die 
wesentlichen funktionalen Anforderungen an die Software formuliert werden. 
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Auf Basis des Lastenheftes wird unter Erhebung von Nutzerwünschen 
und -anforderungen^ eine Produktbeschreibung auf sowohl fachlicher als auch 
technischer Ebene entwickelt. Hierbei ist unter Berücksichtigung übergeord- 
neter Ziele der Organisation die Umsetzung auf Basis technischer und wirt- 
schaftlicher Kriterien zu bewerten. In diesem Rahmen können somit Wirt- 
schaftlichkeitsuntersuchungen und Aufwandsschätzverfahren zur Anwendung 
kommen; vgl. Abschnitt 6.3.2. 

6.1.2 Anforderungsanalyse 

In der Anforderungsanalyse werden verbindliche Anforderungen an das Soft- 
waresystem in einer Anforderungsspezifikation {Pflichtenheft) festgelegt. Dies 
umfasst einerseits eine detaillierte Erarbeitung fachlicher Anforderungen und 
einer einheitlichen Terminologie, was sich insbesondere auf die abzubildenden 
Funktionen und Prozesse sowie die zu Grunde liegenden Daten bezieht. In 
diesem Zusammenhang kann auch eine funktionale Definition der Benutzer- 
oberfläche fest gelegt werden. Andererseits sind die wesentlichen technischen 
Randbedingungen, Schnittstellen zu betroffenen Systemen sowie Qualitäts- 
und Dokumentationsanforderungen festzulegen. 

Die Anforderungsspeziflkation ist die Grundlage für die (späteren) Soft- 
waretests. Weiterhin kann eine Detaillierung des Softwareentwicklungspro- 
jektes erfolgen. 

6.1.3 Entwurf 

Während des Entwurfes {Designs) wird die Softwarearchitektur festgelegt. 
Hierunter versteht man zum einen den statischen Aufbau (die Organisation) 
eines Softwaresystems aus Modulen (Komponenten) mit definierten Schnitt- 
stellen einschließlich ihrer (Verwendungs-)Beziehungen. Zum anderen werden 
im Systementwurf die für die Implementierung zu verwendenden Mechanis- 
men und Techniken erarbeitet (bis hin zur Entwicklung wesentlicher Algo- 
rithmen und Datenstrukturen) . Die Entwurfsentscheidungen sind hinsichtlich 
ihrer Auswirkungen auf Eigenschaften wie u. a. Erweiterbarkeit, Wiederver- 
wendbarkeit und Effizienz abzuwägen. 

Bei komplexen Projekten wird der Entwurf häufig in zwei aufeinander- 
folgende Phasen unterteilt. Im Grobentwurf werden hierbei die wesentlichen 
Entwurfsprinzipien festgeschrieben, während im Feinentwurf die detaillierte 
Beschreibung des Systems entwickelt wird. Alternativ kann in einen fachli- 
chen und einen implementierungstechnischen Entwurf unterschieden werden. 

Im Entwurf können die in Kapitel 4 beschriebenen Modellierungsmetho- 
den verwendet werden. Dies bezieht sich etwa auf die Datenmodellierung 

^ Unter Nutzern oder Anwendern sind in diesem Zusammenhang nicht nur Perso- 
nen zu verstehen, sondern auch andere Softwaresysteme, die die zu entwickelnde 
Software „verwenden“ werden. 
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und die objektorientierte Modellierung. Auf der implementierungstechnischen 
Ebene können hierauf aufbauend konkrete Festlegungen hinsichtlich der zu 
verwendenden Hardware und Systemsoftware sowie der Implementierungs- 
umgebung (insbesondere der Programmiersprache) getroffen werden. 

Der Entwurf mündet in einer Entwurfsspezifikation. In diesem Rahmen 
sind auch der Testplan zu konkretisieren sowie gegebenenfalls ein Integrati- 
onsplan zu entwickeln. 

6.1.4 Implementierung 

Die Implementierung umfasst die eigentliche Erstellung (Programmierung) 
der Software. Das heißt, der Systementwurf wird in Programmcode umge- 
setzt. In diesem Rahmen können verschiedene Softwarewerkzeuge wie Pro- 
grammierumgebungen bzw. CASE-Tools zum Einsatz kommen. Im Idealfall 
können Teile des Systementwurfes automatisiert in Programmcode übersetzt 
werden, wodurch eine Entsprechung von Entwurf und Implementierung un- 
mittelbar gewährleistet ist. 

Im Sinne eines integrativen Qualitätsmanagements sind bereits während 
der Implementierung (gegebenenfalls isolierte) Tests der entwickelten Kom- 
ponenten vorzunehmen. Im Hinblick hierauf und die nachfolgende Wartung 
und Pflege ist die Implementierung zweckmäßig zu dokumentieren. 

6.1.5 Test, Integration und Einführung 

„Testen ist der Prozeß, ein Programm mit der Absicht auszuführen, 
Fehler zu finden. [. . .] Testen [ist] ein destruktiver, ja geradezu ein 
sadistischer Prozeß.“ (Myers (2001), S. 4) 

Bevor ein Softwareprodukt (bzw. eine neue Version) real eingesetzt wer- 
den kann, ist die Korrektheit gemäß der Anforderungsspezifikation zu über- 
prüfen [Verifikation). Da hierfür im praktischen Umfeld nur sehr einge- 
schränkt effektive analytische Methoden existieren, erfolgt dies insbesondere 
auf Basis experimenteller Tests.^ Im einfachsten Fall erfolgt eine Überprüfung 
der durch die Software erzielten Ergebnisse mit vordefinierten Testfällen (auf 
Basis erwarteter Ein-/ Ausgabe-Kombinationen unter Berücksichtigung von 
Realdaten). Hiermit können in der Regel jedoch nur Fehler aufgedeckt, nicht 
aber die Korrektheit im Sinne einer Fehlerfreiheit nachgewiesen werden. 

Da die Korrektheit eines Softwaresystems nur im Zusammenspiel al- 
ler beteiligten (Teil-)Systeme entsprechend der späteren Anwendungsumge- 
bung beurteilt werden kann, ist nach Tests einzelner Komponenten bzw. 
(Teil-)Systeme und einer (sukzessiven) Integration auch das Gesamtsys- 
tem zu überprüfen. Zweckmässigerweise untergliedert man den entsprechen- 
den Integrationsprozess hierarchisch und bewertet sukzessive komplexere 
(Teil-)Systeme. 

Vgl. z. B. Myers (2001) sowie Thaller (2000). 
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Systemtests umfassen neben der Überprüfung der fachlichen Anforderun- 
gen auch sekundäre Qualitätseigenschaften wie etwa Effizienz und Porta- 
bilität. Vor der letztendlichen Einführung ist weiterhin zu überprüfen, ob 
die entwickelte Software für ihren vorgesehenen praktischen Einsatz geeignet 
ist ( Validation / Validierung) , wodurch letztlich die Anforderungsspezifikation 
selbst Gegenstand der Kontrolle ist. Eine nicht erfolgreiche Validation kann 
darauf hindeuten, dass die Anforderungen nicht korrekt erfasst wurden bzw. 
sich die Anforderungen inzwischen geändert haben. 

Die Verifikation und die Validation bilden die Basis für die Abnahme der 
Software. Vor der Einführung sind weiterhin System- und Nutzerdokumen- 
tationen abschließend zu erstellen sowie gegebenenfalls Nutzerschulungen zu 
konzipieren und ein Migrationskonzept zur Ersetzung von Altsystemen und 
zur Eingliederung in die Anwendungssystemumgebung zu entwickeln. 

6.1.6 Wartung und Pflege 

Im Verlauf der realen Nutzung der Software werden in der Regel Fehler festge- 
stellt. Die fortlaufende Durchführung entsprechend notwendiger Korrekturen 
des Softwaresystems nach Inbetriebnahme bezeichnet man als Wartung. Un- 
ter Pflege versteht man dagegen die (geringfügige) Anpassung der Software 
an veränderte bzw. erweiterte Anforderungen. Anpassungen können etwa auf- 
grund neuer Nutzerwünsche, gesetzlicher Neuerungen oder Änderungen der 
Systemumgebung notwendig werden. 

Wartung und Pflege führen zu neuen Versionen {Releases) einer Software. 
Vor der Einführung einer neuen Version ist diese im Sinne einer umfassenden 
Qualitätssicherung zu testen. 

6.1.7 Qualitätssicherung 

Bei der Entwicklung von Software muss, wie bei jeder Produktentwicklung, 
auf die Qualität Augenmerk gelegt werden. Softwarequalität ist nach DIN ISO 
9126 die Gesamtheit aller Merkmale und Merkmalswerte eines Softwarepro- 
duktes, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte 
Erfordernisse zu erfüllen. 

Im Sinne einer umfassenden Qualitätssicherung ist es nicht ausreichend, 
am Ende des Entwicklungsprozesses Qualitätsmängel aufdecken und behe- 
ben zu wollen. Die Qualitätssicherung ist vielmehr eine Querschnittsfunktion, 
die in jeder Aktivität des Entwicklungsprozesses sowohl produktorientiert als 
auch prozessorientiert Berücksichtigung Anden muss. Das heißt, sowohl der 
eigentliche Ablauf von Entwicklungsprozessen als auch alle hierbei erstellten 
Artefakte (z.B. Zwischenergebnisse wie Pflichtenheft, Anforderungsspeziflka- 
tion, Entwurfsspeziflkation, Dokumentation) sind Gegenstand der Qualitäts- 
sicherung. 
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Softwarequalität wird durch Qualitätsmerkmale {Qualitätsfaktoren) be- 
schrieben. Diese können in Teilmerkmale untergliedert werden, die dann mit- 
tels Qualitätsindikatoren bzw. Metriken messbar oder bewertbar sein sollten. 
Allerdings sind Qualitätsmerkmale wie z. B. Benutzerfreundlichkeit nur ein- 
geschränkt objektiv bewertbar (oder gar quantifizierbar). 

Der primäre Qualitätsfaktor von Software ist die Funktionalität. Damit 
wird der Nutzen, der aus Software zu ziehen ist, im Wesentlichen daran ge- 
messen, welche Funktionen diese dem Nutzer auf korrekte Art und Weise, 
unter Berücksichtigung seiner Anforderungen, in benutzerfreundlicher Weise 
bietet. In diesem Zusammenhang sind verschiedene sekundäre Qualitätsfak- 
toren zu berücksichtigen, die im Weiteren erläutert werden. 

• Erweiterbarkeit/ Anpassbarkeit: Hierunter wird die Eigenschaft verstanden, 
an erweiterte oder veränderte Anforderungen (z.B. im Rahmen von War- 
tung und Pflege) möglichst einfach und effizient anpassbar zu sein. 

• Robustheit: Während Korrektheit das Verhalten von Software in von der 
Spezifikation abgedeckten Situationen umfasst, versteht man unter Ro- 
bustheit die Eigenschaft, sich auch bei anomalen Situationen angemessen 
zu verhalten (Beispiel: Fehlschlagen einer Dateioperation). Aufgrund des 
engen Zusammenhanges zwischen Korrektheit und Robustheit kann man 
beide Eigenschaften unter dem Begriff Zuverlässigkeit zusammenfassen. 

• Effizienz: Unter Effizienz sei hier die Eigenschaft von Software verstanden, 
zur Lösung einer Problemstellung relativ wenig Ressourcen (wie Prozessor- 
zeit, Speicherplatz, Kommunikationsbandbreite u.A.) zu verwenden. Die 
Ziele der Verringerung der verschiedenen Ressourcenbeanspruchungen sind 
typischerweise sowohl untereinander als auch bezüglich anderer Qualitäts- 
faktoren konkurrierend, was in der Regel situative Kompromisse erfordert. 
Beispielsweise wird man bei einem Steuerungssystem mit Realzeitanforde- 
rungen gegebenenfalls andere Ziele der Laufzeiteffizienz unterordnen. 

• Portabilität und Kompatibilität: Unter Portabilität versteht man die Ei- 
genschaft von Software, auf der Grundlage verschiedener Rechnersysteme 
ablauffähig zu sein, was insbesondere durch Verwendung einer standardi- 
sierten, portablen Programmiersprache erreicht werden kann. Systembe- 
standteile, die unter Erfüllung gewisser Anforderungen in ein bestimmtes 
(Gesamt-)System integriert werden können, werden in diesem Kontext als 
kompatibel bezeichnet. 

• Wiederverwendbarkeit: Während sich die bisher aufgeführten Qualitätsfak- 
toren an einem Softwareprodukt (bzw. verschiedenen Versionen desselben) 
orientieren, ermöglicht Wiederverwendbarkeit bei ähnlichen Anforderun- 
gen eine produktübergreifende Verwendung von Software, was sowohl zur 
Aufwandssenkung als auch Qualitätssteigerung bei entsprechenden Ent- 
wicklungsprojekten beitragen kann. Wiederverwendbarkeit bedingt in der 
Regel eine hinreichende Anpassbar keit/Konflgurierbarkeit von Software- 
komponenten; vgl. Abschnitt 6.4. 
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Eine qualitätsgerechte Softwareentwicklung setzt eine situative Bestim- 
mung relevanter Qualitätsmerkmale und der zu erreichenden Bewertungen 
voraus. Die sich hieraus ergebenden Qualitätsanforderungen sollten bei der 
Ausgestaltung des jeweiligen Entwicklungsprozesses berücksichtigt werden. 
In diesem Zusammenhang formuliert Balzert (1998), S. 284-293, folgende 
allgemeine Prinzipien der Qualitätssicherung: 

• Prinzip der produkt- und prozessahhängigen Qualitätszielbestimmung: Ex- 
plizite Bestimmung der Qualitätsmerkmale und -anforderungen vor Beginn 
der eigentlichen Entwicklung 

• Prinzip der quantitativen Qualitätssicherung: Ständiges Messen und Be- 
werten von Qualitätsmerkmalen im Entwicklungsprozess 

• Prinzip der maximalen konstruktiven Qualitätssicherung: Anwendung 
möglichst vieler Maßnahmen, die bestimmte Fehler von vornherein aus- 
schließen (z.B. Verwendung bestimmter Programmiersprachen) 

• Prinzip der frühzeitigen Fehlerentdeckung und -hehehung: Fehlersuche nicht 
erst nach Beendigung der Implementierung, sondern jederzeit in allen Pha- 
sen des Entwicklungsprozesses 

• Prinzip der entwicklungshegleitenden, integrierten Qualitätssicherung: In- 
tegrative Qualitätssicherung in allen Aktivitäten des Entwicklungsprozes- 
ses 

• Prinzip der unabhängigen Qualitätssicherung: Durchführung der Qualitäts- 
sicherung auch von Personen, die nicht direkt mit der korrespondierenden 
Entwicklung befasst sind 



6.2 Vorgehensmodelle 

Für eine effiziente Durchführung von Softwareentwicklungsprojekten ist eine 
zweckmäßige (Ablauf-) Organisation des Entwicklungsprozesses nötig. So ge- 
nannte Vorgehensmodelle {Prozessmodelle) definieren hierfür entsprechende 
Rahmenvorgaben. Dies bezieht sich insbesondere auf Phasenschemata, die 
die Reihenfolge der Durchführung von Aktivitäten unter Berücksichtigung 
wechselseitiger Abhängigkeiten vorgeben, ohne hiermit unbedingt entwick- 
lungstechnische Methoden festzulegen."* 

Die Anwendung eines zweckmäßigen Vorgehensmodells soll zu einer ef- 
fektiven und effizienten Entwicklung komplexer Softwaresysteme führen. Bei 
umfangreichen Projekten ist insbesondere eine systematische Feingliederung 
von Aktivitäten einschließlich der Definition zu erzeugender Artefakte (Zwi- 
schenergebnisse) hilfreich. Hiermit korrespondiert die Festlegung so genannter 
Meilensteine, die den Abschluss von Phasen kennzeichnen. Die Orientierung 
an entsprechenden ablauforganisatorischen Vorgaben des Vorgehensmodells 

^ Allerdings können Vorgehensmodelle dnrchaus (Mindest-)Anfordernngen an die 
entwicklungstechnische Methode wie z.B. die Programmiersprache oder Soft- 
warewerkzenge nach sich ziehen; vgl. die Abschnitte 6.2.3 und 6.2.4. 
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ist die Grundlage für eine effektive Kontrolle und Steuerung des Entwick- 
lungsprozesses. 

Im Weiteren werden verschiedene gängige Vorgehensmodelle kurzgefasst 
behandelt, wobei zur Verdeutlichung insbesondere die jeweils auszeichnenden 
Prinzipien diskutiert werden.® Zuvor ist allerdings davor zu warnen, irgend- 
welche der nachfolgend beschriebenen Ansätze als Allheilmittel zu betrach- 
ten. Gerade vor dem Hintergrund immer komplexerer Anwendungsbereiche 
stellt die Entwicklung von Software eine komplexe Aufgabe dar, und der 
Aussage „There is no silver bullet.“ (Brooks (1987)) ist weiterhin Gültigkeit 
zuzusprechen; vgl. hierzu z.B. auch Brooks (1995) sowie McGonnell (1996). 

6.2.1 Wasserfallmodell 

Das einfachste Vorgehensmodell ist das so genannte Wasserfallmodell; vgl. 
Abbildung 6.2. Es korrespondiert unmittelbar mit der natürlichen Reihen- 
folge der Aktivitäten entsprechend der Darstellung in Abschnitt 6.1. Diese 
Aktivitäten bilden abgeschlossene Phasen, die im einfachsten Fall einmalig 
streng sequenziell durchlaufen werden. Rücksprünge in der Entwicklung im 
Sinne einer Erweiterung oder Veränderung der Ergebnisse vorangegangener 
Phasen sind dann nicht möglich. Dies führt zur Analogie des Wasserfalles, 
bei dem der Fluss streng in eine Richtung orientiert ist (die Ergebnisse einer 
Phase „fallen nur nach unten“). 




Abbildung 6.2. Wasserfall- Vorgehensmodell 



® Für die im Rahmen von Vorgehensmodellen zu betrachtenden Aspekte des ei- 
gentlichen Projektmanagements verweisen wir außerdem auf Abschnitt 6.3 sowie 
z.B. Royce (1998). 
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Offensichtlich kann es aber notwendig sein, dass aufgrund von Erkennt- 
nissen in nachgelagerten Phasen Aufgaben einer vorherigen Phase nachbear- 
beitet werden müssen. Beispielsweise kann sich in der Entwurfsphase heraus- 
steilen, dass Anforderungen unklar erfasst sind; oder bei der Implementie- 
rung wird festgestellt, dass der Entwurf unvollständig oder inkonsistent ist. 
Dementsprechend beinhaltet das von Royce (1970) vorgeschlagene Wasser- 
fallmodell bereits Rückkopplungsschleifen um jeweils eine Phase. Das heißt 
Z.B., dass ausgehend von der Implementierungsphase der Entwurf verändert 
werden kann, nicht aber die Anforderungsspezifikation. 

Ein solches sequenzielles Vorgehen ist zwar einfach, verständlich und ge- 
gebenenfalls mit relativ geringem Koordinierungsaufwand durchführbar. Je- 
doch wird dabei angenommen, dass eine Phase im Ganzen (im vollen De- 
taillierungsgrad) abschließend bearbeitet wird, bevor der Aufgabenbereich 
der folgenden Phase betrachtet wird. Beispielsweise wird vorausgesetzt, dass 
im Rahmen der Anforderungsanalyse eine vollständige und widerspruchsfreie 
Spezifikation entsteht. Dem stehen Erfahrungen dahingehend entgegen, dass 
sich im Projektverlauf typischerweise Anforderungen ändern bzw. sich neue 
Anforderungen ergeben. So erscheint es praktisch nicht unbedingt angebracht, 
in einem Entwicklungsprojekt von der Stabilität der Anforderungen auszu- 
gehen und damit letztendlich eventuell an veränderten realen Gegebenheiten 
vorbei zu entwickeln. Dementsprechend sollten Vorgehensmodelle weiter ge- 
hende Rückkopplungsmechanismen vorsehen, um entsprechende Risiken zu 
reduzieren. 

6.2.2 V-Vorgehensmodell 

Das V-(Vorgehens-)Modell ist eine Erweiterung des Wasserfallmodells unter 
Betonung von Qualitätssicherungsaktivitäten; vgl. Boehm (1981, 1984). Dies 
geschieht durch eine Zuordnung von Maßnahmen zur Verifikation und Vali- 
dation/Validierung. Entsprechend der Darstellung in Abschnitt 6.1.5 soll im 
Rahmen der Verifikation überprüft werden, ob das System der Spezifikation 
entspricht (Korrektheit), während die Validation bewertet, inwieweit über- 
haupt das richtige Produkt für den eigentlichen Einsatzzweck entwickelt wur- 
de (Eignung). Die Phasengliederung und direkte Gegenüberstellung von kon- 
struktiven Entwicklungsaktivitäten und Qualitätssicherungsaktivitäten des 
V-Modells sind in Abbildung 6.3 dargestellt. Korrespondierende Aktivitäten 
sind über horizontale Achsen miteinander verbunden. 

Das V-Modell ist insbesondere für relativ große Entwicklungsprojekte auf- 
grund derer hohen Regelungsbedarfe geeignet. Jedoch wird häufig kritisiert, 
dass die (hier nicht dargestellten) umfangreichen Regelungen für die Abwick- 
lung von entsprechenden Entwicklungsprozessen insbesondere bei kleineren 
Projekten ein Übermaß an „Software-Bürokratie“ implizieren.® Wie im Was- 

® Aufgrund der Kritik an der stark gewachsenen Komplexität von Softwareent- 
wicklungsmethoden wurden inzwischen verschiedene neue Ansätze für „schlan- 
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Abbildung 6.3. V-Vorgehensmodell; in Anlehnung an Boehm (1981) 



serfallmodell müssen auch hier umfangreiche und detaillierte Zwischendoku- 
mentationen erstellt werden, da die jeweiligen Phasen relativ lange dauern 
und damit keinesfalls auf das (Kurzzeit-) Gedächtnis von Projektbeteiligten 
vertraut werden kann. 

Das V-Modell ist insbesondere in Behörden gebräuchlich und wird heu- 
te auch verbreitet in der Wirtschaft angewendet. Hierbei werden teilweise 
Erweiterungen eingesetzt, die sich insbesondere auf die Integration einer 
inkrementell-iterativen Vorgehensweise (vgl. Abschnitt 6.2.4) beziehen (V- 
Modell 97, V-Modell XT).'^ 



6.2.3 Prototyping 

Eine wesentliche Problematik der oben dargestellten Vorgehensmodelle be- 
steht darin, dass nach der Erhebung von Benutzeranforderungen häufig eine 
lange Zeitspanne vergeht, bis schließlich ein nutzbares System unter Betei- 
ligung der Anwender validiert werden kann. Mögliche gravierende Fehlent- 
wicklungen sind damit gegebenenfalls erst sehr spät diagnostizierbar, was zu 
einer kosten- und zeitaufwändigen Korrektur führen kann. 

ke“ Vorgehensmodelle entwickelt. Ein Beispiel ist das so genannte Extreme Pro- 
gramming, bei dem das eigentliche Programmieren - im Zusammenhang mit 
intensivem Testen und sukzessivem Umstrukturieren (Refaktorisieren) des Sys- 
tems - wieder in den Mittelpunkt der Softwareentwicklung gestellt wird; vgl. 
Beck (2005). 

^ Vgl. zur Vertiefung Dröschel et al. (1997), Versteegen (1999) sowie o.V. (2004). 
Vgl. ferner auch Gutenschwager et al. (2000), die die Qualitätssicherung lager- 
logistischer Steuerungssoftware durch Simulation auf Basis des V-Modells struk- 
turieren. 
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Deshalb strebt man beim Prototyping eine möglichst schnelle Entwick- 
lung einer rudimentär ablauffähigen Vorversion (Prototyp) des Anwendungs- 
systems an. Hierbei ist die Verwendung unterstützender Softwarewerkzeu- 
ge zweckmäßig (etwa 4GL-Sprachen bzw. CASE-Tools). Am Prototyp sollte 
zumindest die wesentliche fachliche Funktionalität über eine entsprechende 
Benutzeroberfläche erkennbar sein, was als Diskussionsbasis für die weitere 
Entwicklung dienen kann. Hierdurch können die späteren Anwender verstärkt 
in den Entwicklungsprozess integriert werden. 

Man kann verschiedene Arten von Prototypen (bzw. Vorgehensweisen des 
Prototyping) dahingehend unterscheiden, welchem Zweck der Prototyp dient 
und inwieweit der Prototyp im Entwicklungsprozess (nicht) weiterverwendet 
wird (vgl. Balzert (1998)): 

• Ein Demonstrationsprototyp soll im Rahmen der Projektinitiierung einem 
potenziellen Auftraggeber einen ersten Eindruck von dem zu erstellenden 
Produkt vermitteln, um eine Basis für eine nachfolgende Auftragserteilung 
bzw. Projektfreigabe zu schaffen. 

• Ein Prototyp im engeren Sinne dient im Rahmen der Planung und Anfor- 
derungsanalyse der Kommunikation mit den zukünftigen Anwendern des 
Systems. 

• Ein Lahormuster soll in erster Linie projektintern die technische Umsetz- 
barkeit der Anforderungsspeziflkation bzw. eines hierauf aufbauenden Ent- 
wurfes demonstrieren. 

• Ein Pilotsystem beinhaltet die Kernfunktionalität des zu entwickelnden 
Systems und kann bereits in die spätere Systemumgebung integriert wer- 
den. Das heißt, ein Pilotsystem stellt praktisch eine erste Version mit re- 
duzierter Funktionalität dar. 

Prototyping ist nicht als ein vollständiges Vorgehensmodell, sondern eher 
als ein ergänzender Ansatz zu verstehen, durch den Nachteile der oben disku- 
tierten Vorgehensmodelle teilweise behoben werden sollen. Dies bezieht sich 
insbesondere auf die bessere Anwenderintegration bei der Anforderungsana- 
lyse (und teilweise auch Entwicklung), um das Risiko, ein falsches Produkt 
zu entwickeln, zu reduzieren. 

Da ein Prototyp auf einer unvollständigen Anforderungspeziflkati- 
on, einem nur rudimentären Entwurf oder einer ineffizienten Ad-hoc- 
Implementierung basieren kann, ist die Eignung des Prototyps als Basis der 
Implementierung nicht unbedingt gegeben. Dies gilt um so mehr, wenn für 
die Entwicklung des Prototyps Implementierungstechniken und -Werkzeuge 
verwendet wurden, die im Hinblick auf z.B. Stabilität, Effizienz und Kom- 
patibilität nicht den eigentlichen Anforderungen genügen. 

6.2.4 Inkrementell-iterative Softwareentwicklung 

Aufbauend auf der grundsätzlichen Idee eines evolutionären Prototypings 
bzw. der Erkenntnis, dass komplexe Systeme typischerweise nicht in einem 
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einmal zu durchlaufenden sequenziellen Prozess entwickelt werden können, ist 
eine inkrementell-iterative Softwareentwicklung als zweckmäßig zu betrach- 
ten. Hierbei wird explizit eine inkrementeile Systementwicklung zu Grunde 
gelegt, was ein wiederholtes (iteratives) Durchlaufen von Analyse-, Entwurfs- 
und Implementierungsphasen bedeutet. Dabei wird nicht von Anfang an das 
gesamte System geplant, entworfen und schließlich implementiert (sondern 
sukzessiv erweiterte Systemkerne bzw. Teilbereiche). Zusammen mit dem 
Auftraggeber bzw. den Anwendern ist hierfür zu erarbeiten, welche Aspekte 
des zu entwickelnden Systems besonders wichtig sind und damit priorisiert 
behandelt werden sollten. Hierdurch soll relativ frühzeitig ausführbare bzw. 
nutzbare Software entstehen, die den Projektfortschritt deutlich macht und 
entsprechende Rückkopplungen ermöglicht. 

Um sicherzustellen, dass ein letztendlich homogenes und den jeweiligen 
Qualitätsanforderungen genügendes Gesamtsystem entsteht, ist ein inkre- 
menteil ausgerichteter Entwicklungsprozess systematisch zu strukturieren. 
Hierbei wird man nach einem hinreichenden Problemverständnis (im Zu- 
sammenhang mit einer weitgehenden Erfassung der Anforderungen in der 
Analysephase) insbesondere Wert auf eine relativ frühzeitige Erarbeitung ei- 
ner stabilen und erweiterbaren Systemarchitektur legen. Um eine Kontrolle 
und Steuerbarkeit des Entwicklungsprojektes zu gewährleisten, erscheint ei- 
ne möglichst feinkörnige Untergliederung der dann folgenden Teilaufgaben 
(Phasen) mit entsprechenden Zwischenergebnissen (und korrespondierenden 
Meilensteinen) sinnvoll. 

Eine inkrementeile Systemerstellung sollte durch die Verwendung von 
Implementierungstechniken gestützt werden, die eine starke Modulari- 
sierung von Systemen ermöglichen. Insbesondere die objektorientierte 
Vorgehensweise stellt hier entsprechende Mechanismen bereit, weshalb 
inkrementell-iterative Vorgehensmodelle insbesondere auf Basis objektorien- 
tierter Analyse- und Entwurfsmethoden sowie einer objektorientierten Pro- 
grammiersprache angewendet werden. Ein Beispiel für ein solches Vorgehens- 
modell ist der auf der UML basierende Unified Software Development Process; 
vgl. Jacobson et al. (1999). 



6.3 Softwareprojektmanagement 

Die Softwareentwicklung wird in der Regel in einer Projektorganisationsform 
durchgeführt. Weitergehend wird auch die Neueinführung von Informations- 
und Kommunikationssystemen, bei der die eigentliche Softwareentwicklung 
teilweise in den Hintergrund tritt und eher Aufgaben der Anpassung und 
Integration vorhandener Systeme und Standardsoftware eine Rolle spielen, 
ebenfalls typischerweise als Projekt durchgeführt. Dementsprechend werden 
im Folgenden einige Aspekte und Aufgaben des Projektmanagements aus 
einer allgemeinen Sichtweise kurzgefasst betrachtet. Die abschließende Dar- 
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Stellung von Aufwandsschätzverfahren ist dagegen speziell für Softwareent- 
wicklungsprojekte relevant.® 

6.3.1 Begriff und Aufgaben 

Ein Projekt ist nach DIN 69901 ein Vorhaben, das im Wesentlichen durch 
seine Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, 
wie z.B. Ziel Vorgabe, zeitliche, finanzielle, personelle oder andere Begren- 
zungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Orga- 
nisation. Beispiele für als Projekt zu betrachtende Aufgabenstellungen sind 
Bauvorhaben, Forschungsvorhaben, Rationalisierungsmaßnahmen oder eben 
die Entwicklung und Einführung von Informations- und Kommunikationssys- 
temen. 

Eine Differenzierung von Projekten ist vor allem hinsichtlich der Pro- 
jektart und der Branche möglich. Darüber hinaus können weitere Projekt- 
merkmale zur Einordnung herangezogen werden; hierzu zählen z.B. der Pro- 
jektumfang (sowie hiermit eng zusammenhängend Größe und Dauer) und die 
Projektkomplexität (insbesondere auch hinsichtlich struktureller Interdepen- 
denzen von Projektteilaufgaben). 

Durch die typischerweise auftretende Neuartigkeit, Komplexität und 
fachübergreifende Abwicklung von Projekten ist ein entsprechendes Projekt- 
management notwendig. Nach DIN 69901 ist hierunter die Gesamtheit von 
Führungsaufgaben, -Organisation, -techniken und -mittein für die Abwicklung 
eines Projektes zu verstehen. Geht man von einem engeren aufgabenorien- 
tierten Verständnis von Management aus, können unter Projektmanagement 
alle Aktivitäten der Planung, Organisation, Personalausstattung, Überwa- 
chung, des Gontrollings und der Leitung eines Projektes verstanden werden. 
Entsprechende Aufgaben können wie in Abbildung 6.4 dargestellt in sechs we- 
sentliche Bereiche gegliedert werden. Im folgenden Abschnitt werden hieraus 
die Projektplanung und das Projektcontrolling näher betrachtet. 

Projektmanagement ist von den in Abschnitt 6.2 betrachteten Vorge- 
hensmodellen dadurch abzugrenzen, dass dort eine softwareentwicklungstech- 
nische Sicht vorliegt, während Projektmanagement im Allgemeinen anwen- 
dungsunabhängig verstanden wird. Die in konkreten Softwareentwicklungs- 
projekten einzusetzenden Projektmanagementtechniken hängen jedoch offen- 
sichtlich stark von dem zu Grunde gelegten Vorgehensmodell ab. 

6.3.2 Projektplanung und -Controlling 

„Adding manpower to a late Software project makes it later.“ (Brooks 
(1995), S. 25) 

® Zur Vertiefung des Softwareprojektmanagements verweisen wir z.B. auf Jenny 
(2000) und Zielasek (1999). Für eine einsichtsreiche Betrachtung von Problem- 
feldern des Softwareprojektmanagements siehe außerdem Brooks (1995). 
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Definition klarer, erreichbarer und akzeptierter 
Ziele und Zwischenziele als Basis aller Aktivitäten 




Aufbau einer zeitlich befristeten 
Projektorganisation mit personifi- 
zierten Verantwortungen 



Aufbau- 




Ablauf- 



lorganisatioiy lorganisatioiy 



Bestimmung des technisch und 
wirtschaftlich geeigneten 
Projektablaufes 



Planung von realistischen 
und abgestimmten 
Leistungen, Terminen, 
Kapazitäten und Kosten 





Projekt- 

controlling 



Laufende Überwachung 
und sofortige Steuerung 
bei Abweichungen für 
alle Randbedingungen, 
Ziele und Ergebnisse 



Motivation, Engagement und 
Zusammenarbeit aller 

betroffenen Mitarbeiter (Teamarbeit, kooperative Führung) 



Abbildung 6.4. Aufgaben des Projektmanagements; Quelle: Zielasek (1999) 



Ziele der Projektplanung sind eine Vorausschau des Projektgeschehens, 
das Durchdenken alternativer Handlungsmöglichkeiten und die Vorgabe von 
Planungszielen und Planungsgrößen mit der darauf operierenden Möglichkeit 
der Planüberwachung. Im Weiteren werden einige Elemente der Projektpla- 
nung kurzgefasst charakterisiert. 

Die Planung der Vorgehens ziele geschieht auf Basis der Projektziele und 
beinhaltet die Festlegung von Etappenzielen (Phasenzielen), die Planung ein- 
zusetzender finanzieller, personeller und sachlicher Mittel sowie die Festle- 
gung von Terminzielen. Die Aufbauorganisationsplanung umfasst alle Pla- 
nungsaktivitäten, die sich auf das institutionale Projektmanagement bezie- 
hen (Projektorganisation, Bildung von Projektteams usw.). 

Die Strukturplanung befasst sich mit der Zerlegung eines Projektes in Teil- 
aufgaben bzw. Arbeitspakete und der Ermittlung sachlogischer und zeitlicher 
Abhängigkeiten zwischen diesen. Daraus ergibt sich ein Projektstrukturplan, 
der eine primäre Grundlage für die weitere Projektplanung bzw. -abwicklung 
ist. Bei der Projektablauf-, Termin- und Kapazitätsplanung sind die Arbeits- 
pakete des Strukturplanes unter Berücksichtigung von Abhängigkeiten und 
verfügbaren Ressourcen (Personal und Sachmittel) zeitlich anzuordnen. Da- 
bei sind letztlich Zuordnungen von Ressourcen zu Tätigkeiten bzw. Arbeits- 
paketen vorzunehmen. Hierbei werden insbesondere Methoden der Netzplan- 
technik eingesetzt. 

Aufgabe der Kostenplanung ist die Bestimmung der im Projektverlauf 
voraussichtlich entstehenden Kosten und Finanzmittelbedarfe. Entsprechen- 
de Aussagen, die aufgrund von Unsicherheiten problematisch sind, bilden in 
der Regel eine Grundlage für die Entscheidung über die eigentliche Projekt- 
durchführung. In diesem Zusammenhang erfolgt in Abhängigkeit von Finanz- 
mittelbedarfen, die über den geplanten Projektverlauf aufzuschlüsseln sind. 
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typischerweise eine so genannte Projektbudgetierung (Mittelzuordnung und 
zeitgerechte Mittelbereitstellung) . 

Unter Projektcontrolling versteht man eine an Planungsdaten (Terminen, 
Budgetausschöpfung, Kosten usw.) orientierte Überwachung von Projekten 
und die an entsprechenden Soll-Ist-Abweichungen orientierte Projektsteue- 
rung. Bei Abweichungen können Maßnahmen zur Angleichung von Ist- auf 
Soll-Daten oder Anpassungen von Planungsdaten ausgelöst werden. Beispiels- 
weise könnte man bei einer Terminverzögerung eines Arbeitspaketes versu- 
chen, durch verstärkten Personaleinsatz eine Beschleunigung zu erreichen. 
In praktischen Projekten stellen sich solche Zusammenhänge typischerweise 
aber komplizierter dar.® 

Die fachliche Realisierungskontrolle ist zwar gegebenenfalls durch das Pro- 
jektcontrolling begleitend zu koordinieren, wird im Allgemeinen aber eher 
als Aufgabe der Qualitätssicherung betrachtet. Gegenstand sind produkt- 
und projektbezogene Messungen des Grades der Realisierung von (quanti- 
tativen oder qualitativen) Zielvorgaben. Der Projektfortschritt definiert sich 
formal als der Fertigstellungsgrad (Quotient aus fertigem Arbeitsvolumen 
durch gesamtes Arbeitsvolumen) der durchzuführenden Entwicklungsarbei- 
ten. Die Messung des Projektfortschrittes ist in der Praxis häufig problema- 
tisch, etwa weil der Aufwand für noch zu leistende Arbeit unterschätzt wird, 
im weiteren Verlauf des Projektes auftretende Probleme unterschätzt wer- 
den oder tatsächlich nicht voraussehbar sind oder „geschönte“ Aussagen der 
Entwickler durch Druck der Projektleitung bewirkt werden. 

Der relative Fertigstellungsgrad eines Arbeitspaketes gibt Aufschluss, zu 
wie viel Prozent ein Arbeitspaket bis zum aktuellen Zeitpunkt fertig gestellt 
wurde. Schwierig für die Berechnung des relativen Fertigstellungsgrades ist 
die angesprochene Problematik bezüglich der objektiven Einschätzung, wel- 
che Aufgaben innerhalb eines definierten Arbeitspaketes tatsächlich noch aus- 
stehen. Der Fertigstellungsgrad eines Projektes kann alternativ zu der pro- 
zentualen Berechnung anhand der definierten Projekt-Meilensteine bestimmt 
werden. Eine Auflistung der bereits realisierten sowie noch ausstehenden Mei- 
lensteine gibt den aktuellen Projektfortschritt an. 

Mittels Restschätzungen während der Projektabwicklung wird der Ver- 
such unternommen, noch ausstehenden Aufwand (z. B. Kosten oder Entwick- 
lungszeit) bis zum geplanten Projektende zu schätzen, um auf diese Weise 
Planungsdaten dynamisch anpassen zu können. Im Allgemeinen erweisen sich 
Restschätzungen erst zu einem fortgeschrittenen Projektstadium als aussa- 
gekräftig. 

6.3.3 Aufwandsschätzung 

Eine effektive Projektplanung benötigt zweckmäßige Verfahren zur quantita- 
tiven Aufwandsschätzung. Konkrete Aufwandsschätzverfahren sind abhängig 

® Vgl. hierzu das Eingangszitat zu diesem Abschnitt auf S. 190. 
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vom Aufgabenbereich. Im Weiteren erfolgt eine Einschränkung auf Software- 
entwicklungsprojekte. Ziel einer Aufwandsschätzung für die Projektabwick- 
lung ist in der Regel eine Schätzung des Entwicklungsaufwandes, typischer- 
weise bewertet in Personenmonaten. Entsprechende Schätzwerte sind aller- 
dings nur ein einfacher Anhaltspunkt, da man Alternativen für einen mögli- 
chen Schätzwert von z. B. einem Personenjahr in der Regel nicht gleichsetzen 
kann („ein Entwickler arbeitet zwölf Monate“ versus „zwölf Entwickler ar- 
beiten jeweils einen Monat“). 

Aufwandsschätzverfahren basieren häufig auf empirisch abgeleiteten Zu- 
sammenhängen (Erfahrungsdaten). Dabei geht man von der Hypothese aus, 
dass solche Zusammenhänge, die aus bereits abgeschlossenen Projekten abge- 
leitet wurden, in hinreichendem Ausmaß auch für neue Projekte gültig sind. 
Im Allgemeinen liegt hier die Annahme von funktionalen Abhängigkeiten zwi- 
schen Eingabeparametern (Kenngrößen) und dem Entwicklungsaufwand zu 
Grunde. Eine Schätzung des Entwicklungsaufwandes beruht damit sowohl auf 
der Verwendbarkeit der angenommenen Formel als auch auf der Schätzung 
der Kenngrößen. Die Messung von Kenngrößen wird mittels so genannter 
(Software-) Metriken festgelegt. Eine Aufwandsschätzung basiert typischer- 
weise wesentlich auf der Funktionalität des zu erstellenden Softwaresystems, 
die damit über entsprechende Kenngrößen zu repräsentieren ist. 

Nachfolgend wird zur Verdeutlichung beispielhaft die Function-Point- 
Methode als ein einfaches Verfahren erläutert. Ein relativ weit verbreite- 
tes Aufwandsschätzverfahren ist die COCOMO-Methode {Constructive Cost 
Model) bzw. COCOMO II; vgl. Boehm et al. (2001). Für weitere Verfahren 
zur Aufwandsschätzung verweisen wir außerdem auf Jones (1998). 

Die Function-Point-Methode wurde Ende der 1970er Jahre bei IBM in 
den USA entwickelt. Sie basiert auf der Grundidee, dass Funktionen der Auf- 
gabenstellung nach Art, Umfang und Schwierigkeitsgrad über so genannte 
Function Points bewertet werden. Diese Kenngrößen werden über eine em- 
pirisch ermittelte Formel (Erfahrungswerttabelle, Function-Point-Kurve) in 
den Entwicklungsaufwand (bewertet in Personenmonaten) transformiert. Im 
Folgenden wird der Ablauf der Function-Point-Methode schrittweise darge- 
stellt: 

1. Auf Basis einer Anforderungsanalyse wird jede Produktanforderung 
(Funktion) einer der folgenden Funktionsarten zugeordnet: 

a) Eingabedaten (z. B. Formulare, Bildschirmmasken) 

b) Ausgabedaten (z.B. Bildschirmmasken, Listen) 

c) Datenbestände (interne Dateien) 

d) Referenzdateien (nur Lesezugriffe und keine Pflege der Daten durch 
das zu erstellende Softwareprodukt) 

e) Abfragen 

2. Für jede Funktionsart werden drei Schwierigkeitsgrade (einfach, mit- 
tel, komplex) eingeführt. Für jede Kombination aus Funktionsart und 
Schwierigkeitsgrad (Komplexität) wird ein Schwierigkeitsgradwert im Be- 
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reich von 3 bis 15 geschätzt (15 repräsentiert die höchste Schwierig- 
keit). Jeder Funktion kann nun ein Schwierigkeitsgrad und damit ein 
entsprechender Schwierigkeitsgradwert zugewiesen werden. Die Summe 
aller Schwierigkeitsgradwerte der Funktionen wird mit S1 bezeichnet. 

3. In diesem Schritt werden verschiedene Einflussfaktoren (vgl. das nach- 
folgende Beispiel) berücksichtigt. Jeder Einflussfaktor wird mittels ei- 
ner Skala von 0 (kein Einfluss) bis 5 (starker Einfluss) bewertet. Die 
Summe der Einflussfaktoren S2 darf maximal 60 Punkte ergeben. Das 
heißt, die einzelnen Bewertungen müssen so gewählt werden, dass die- 
se Summe nicht überschritten wird und die über verschiedene bewer- 
tete Einflussfaktoren repräsentierte Schwierigkeit des Projektes wider- 
gespiegelt wird. Der Einflussbewertungsfaktor S3 wird nach der Formel 
S3 = 0,70 -k S2/ 100 berechnet. 

4. Die bewerteten Function Points (BFP) werden als Produkt der Summe 
S1 und des Faktors der Einflussbewertung S3 berechnet. 

5. Mittels einer auf Erfahrungswerten basierenden Wertetabelle wird aus 
den BFP der Aufwand in Personenmonaten abgeleitet. 

Zur Verdeutlichung wird die Function-Point-Methode an einem Beispiel 
veranschaulicht; vgl. Jenny (2000). Tabelle 6.2 stellt die Schwierigkeitsgrad- 
werte für alle Funktionsart-Schwierigkeitsgrad-Kombinationen dar. 



Funktionsart 


einfach 


mittel 


komplex 


Eingabedaten 


3 


4 


6 


Ausgabedaten 


4 


5 


7 


Datenbestände 


7 


10 


15 


Referenzdaten 


5 


7 


10 


Abfragen 


3 


4 


6 



Tabelle 6.2. Bewertung der Funktionen 



Unter der Annahme entsprechender Anzahlen an Produktanforderungen 
(Funktionen) ergibt sich in Tabelle 6.3 die Summe S1 aller Schwierigkeits- 
gradwerte der Funktionen zu 719. 

Im folgenden Schritt wird die Summe der Einflussfaktoren bestimmt. Da- 
zu werden alle Einflussfaktoren des Projektes aufgelistet und mit einem Ge- 
wicht von 0 bis 5 bewertet; vgl. Tabelle 6.4. Die Gewichtung erfolgt so, dass 
die Summe der Bewertungen die Komplexität des Projektes widerspiegelt. 
Der Einflussfaktor „Verarbeitungskomplexität“ ist in diesem Beispiel unter- 
gliedert worden. Die Summe der Einflussfaktoren S2 beträgt somit 32. 

Der Faktor der Einflussbewertung S3 ergibt sich zu 0,7 -I- 32/100 = 1,02. 
Der Wert der bewerteten Function Points beträgt damit BFP = 719 • 1,02 = 
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Funktionsart 


Schwierigkeitsgrad 


Menge 




Gewicht 




Total 




einfach 


11 


X 


3 


= 


33 


Eingabedaten 


mittel 


15 


X 


4 


= 


60 




komplex 


18 


X 


6 


= 


108 




einfach 


7 


X 


4 




28 


Ausgabedaten 


mittel 


19 


X 


5 


= 


95 




komplex 


5 


X 


7 


= 


35 




einfach 


2 


X 


7 


= 


14 


Datenbestände 


mittel 


4 


X 


10 


= 


40 




komplex 


9 


X 


15 


= 


135 




einfach 


2 


X 


5 


= 


10 


Referenzdaten 


mittel 


0 


X 


7 


= 


0 




komplex 


7 


X 


10 


= 


70 




einfach 


3 


X 


3 


= 


9 


Abfragen 


mittel 


7 


X 


4 


= 


28 




komplex 


9 


X 


6 


= 


54 


Summe S1 


719 



Tabelle 6.3. Berechnung der Summe S1 (Beispiel) 



Einflussfaktoren 


Bewertung 


Verflechtung mit anderen Systemen 


2 


Dezentrale Verarbeitung und Datenhaltung 


3 


Transaktionsrate und Antwortzeitverhalten 


2 


Verarbeitungskomplexität : 

- Schwierigkeit und Komplexität der Rechenoperationen 


5 


- Umfang der Kontrollverfahren für die Datensicherstellung 


3 


- Anzahl der Ausnahmeregelungen 


5 


- Schwierigkeit und Komplexität der Logik 


4 


Wiederverwendbarkeit 


1 


Datenbestand-Konvertierungen 


2 


Benutzer- und Änderungsfreundlichkeit 


5 


Summe S2 


32 



Tabelle 6.4. Berechnung der Summe S2 (Beispiel) 



733,38. Aus einer (hier nicht dargestellten) Wertetabelle wird ein entspre- 
chender Entwicklungsaufwand in Personenmonaten abgelesen. 

Der Ablauf der Function-Point-Methode verdeutlicht die offensichtliche 
Problematik von Aufwandsschätzverfahren. Valide Ergebnisse beruhen auf 
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einer Reihe kritischer Annahmen. Für das Funktionieren der Function-Point- 
Methode für ein konkretes Softwareentwicklungsprojekt wird zunächst vo- 
rausgesetzt, dass die Anforderungsanalyse eine relativ vollständige und detail- 
lierte Aufstellung von Funktionen liefert, für die ex-ante ein Schwierigkeits- 
grad bestimmt werden muss. Die Schätzung der projektspezifischen Schwie- 
rigkeitsgradwerte der Funktionsarten sowie die Bewertung der Einflussfak- 
toren ist ebenfalls problematisch. Weiterhin wird davon ausgegangen, dass 
die empirisch ermittelten Formelbeziehungen sowie die Wertetabelle für den 
Entwicklungsaufwand hinreichend valide sind. Gerade aber durch die Dyna- 
mik von Softwareentwicklungstechniken und neuer Randbedingungen (z.B. 
veränderte Benutzeroberflächen, Client-Server-Technik, Objektorientierung) 
ergeben sich stark veränderte Situationen, die zu einer (gegebenenfalls unter- 
nehmensspezifischen) Neubestimmung bzw. laufenden Anpassung dieser Er- 
fahrungswerte oder gar der grundsätzlichen Vorgehensweise führen müssten. 



6.4 Wiederverwendung von Software 

Die Effizienz der Softwareentwicklung kann u. a. dadurch gesteigert werden, 
dass so genannte (Software-) Komponenten anwendungs-, rechner- oder platt- 
formübergreifend wiederverwendet werden. Deshalb ist Softwarewiederver- 
wendung als ein wichtiges Ziel im Rahmen der Softwareentwicklung zu be- 
trachten. Wiederverwendung bedeutet typischerweise die Nutzung von einer 
Komponente in einem neuen Kontext, weshalb eine Komponente in einem 
gewissen Ausmaß anpassbar sein sollte. Um eine Wiederverwendbarkeit zu 
erreichen, ergeben sich damit zwei wesentliche Ansatzpunkte. Zum einen 
müssen Implementierungstechniken entwickelt bzw. verwendet werden, die 
eine effektive Anpassung von Komponenten ermöglichen. Zum anderen ist 
anzustreben, im Rahmen von Analyse und Entwurf möglichst viele Variati- 
onsanforderungen bereits zu berücksichtigen. 

Die Sinnhaftigkeit einer systematischen Wiederverwendung von Software 
wird aus der häufig auftretenden Arbeitsweise von Programmierern deut- 
lich. Diese werden bei einer nicht vollkommen neuen Aufgabenstellung ty- 
pischerweise versuchen, auf eigenen Quellcode zurückzugreifen. Das heißt, 
man muss geeignete Bestandteile alter Programme finden, diese (neu) ver- 
stehen, entsprechende Teile hiervon kopieren und modifizieren usw. Dieser 
herkömmliche Prozess ist jedoch fehleranfällig, ineffizient und funktioniert 
normalerweise nicht in größeren Entwicklungsgruppen. 

Im Folgenden werden drei Ansätze bzw. Techniken erläutert, die einen 
Beitrag für eine verstärkte Wiederverwendung von Software leisten können: 
objektorientierte Softwaretechnik, Domain Engineering sowie Komponenten- 
techniken.^^ Allerdings ist anzumerken, dass die Einführung solcher Techni- 
ken in Unternehmen allein nicht ausreichend ist, da eine effektive Software- 

Die folgenden Ausführungen basieren teilweise auf Fink (2000). 
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Wiederverwendung eine entsprechend ausgerichtete „Softwareentwicklungs- 
kultur“ mit zweckmäßigen organisatorischen Regelungen voraussetzt. Dies ist 
insbesondere deshalb wichtig, weil sich die Entwicklung wiederverwendbarer 
Software in der Regel erst in Folgeprojekten auszahlt, weshalb unter dem 
typischen Zeitdruck eines Softwareentwicklungsprojektes ein entsprechender 
Mehraufwand nicht per se akzeptiert wird; vgl. z. B. Jacobson et al. (1997). 

6.4.1 Objektorientierte Softwaretechnik 

Objektorientierte Softwareentwicklung kann als ein wichtiges Werkzeug 
zur inkrementeilen Entwicklung von Software betrachtet werden; vgl. Ab- 
schnitt 6.2.4. Mittels Objektorientierung wird eine durchgängige Abbildung 
von Konzepten des Anwendungsbereiches über objektorientierte Analysemo- 
delle und einen objektorientierten Entwurf auf Module einer objektorien- 
tierten Implementierung angestrebt. Bei anderen Vorgehens weisen ergeben 
sich häufig Brüche beim Übergang von der Analyse zum Entwurf bzw. vom 
Entwurf zur Implementierung. Daher ist die Objektorientierung insbesonde- 
re im Rahmen einer inkrementell-iterativen Vorgehensweise hilfreich, da hier 
vielfache Phasenübergänge bzw. simultane Entwicklungen auf verschiedenen 
Ebenen stattfinden. 

Im Gegensatz zur funktionalen Dekomposition zeichnet sich die objekt- 
orientierte Vorgehensweise durch eine Dekomposition der Problemstellung 
primär anhand von Objekten bzw. Objekttypen des Anwendungsbereiches 
aus; vgl. Abschnitt 4.5. Im Hinblick auf die Wiederverwendbarkeit entspre- 
chender objektorientierter Module definiert Meyer (1997) fünf Anforderungen 
wie u. a. Mechanismen zur Gruppierung zusammengehöriger Methoden, Va- 
riation der Implementierung und Faktorisierung gemeinsamer Gharakteristi- 
ka, die weitgehend mittels der Prinzipien der Klassenbildung und Vererbung 
erfüllt werden können. Diese für die objektorientierte Vorgehensweisen zen- 
tralen Mechanismen wurden bereits in Abschnitt 4.5 dargestellt. 

Im Rahmen der objektorientierten Softwaretechnik werden die verschie- 
denen Modellierungs- und Implementierungstechniken in weitgehend kompa- 
tibler Form in verschiedenen Phasen des Entwicklungsprozesses verwendet. 
Letztendlich zielt man hier darauf ab, auf der Grundlage objektorientier- 
ter Spezifikationsmodelle (insbesondere unter Verwendung der UML) quasi- 
automatisch die Anwendungssystemimplementierung generieren zu können 
(„Model Driven Architecture“, MDA); dieser Idealfall lässt sich aber bisher 
nur unter großen Einschränkungen verwirklichen. 

Zur Erläuterung der Durchgängigkeit objektorientierter Modelle auf ver- 
schiedenen Ebenen beziehen wir uns auf das in Abschnitt 4.5 verwendete Bei- 
spiel der Gontainerumschlaggeräte, die im Rahmen der Entwicklung eines Ab- 
laufdispositionssystems berücksichtigt werden müssen. Das in Abbildung 4.31 
dargestellte Klassendiagramm ist in dem verwendeten Abstraktions- bzw. 
Detaillierungsgrad Teil eines groben Analysemodells. Im Rahmen des Soft- 
wareentwurfes müsste das Klassendiagramm insbesondere durch eine Ver- 
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vollständigung und Detaillierung der Schnittstellen erweitert werden. Ent- 
sprechende Objekte der Containerumschlaggeräteklassen könnten in einem zu 
entwickelnden System die Rolle eines Platzhalters für die realen Geräte ein- 
nehmen und würden dabei als Schnittstelle für die Übermittlung von Steue- 
rungsanweisungen dienen. 

Im Rahmen der objektorientierten Implementierung würde auf Basis ei- 
ner objektorientierten Programmiersprache wie z. B. C^, Java oder VB.NET 
eine Umsetzung der Implementierung der Klassen erfolgen. Hierbei würde 
die Klasse Containerumschlaggerät abstrakt implementiert werden. Eine sol- 
che Klasse dient lediglich zur Implementierung gemeinsamer Eigenschaften 
und Methoden der spezialisierten Klassen; Objekte einer abstrakten Klasse 
können nicht konstruiert werden. 

Im Hinblick auf eine angestrebte Abbildung von Charakteristika einer 
„allgemeinsten“ Klasse wird die Schnittstelle von Methoden, die zwar für 
alle spezialisierten Klassen existieren, andererseits aber verschiedenartig zu 
implementieren sind, in der allgemeinen Klasse definiert, die eigentliche Im- 
plementierung dagegen in der spezialisierten Klasse durchgeführt. Ein Bei- 
spiel hierfür ist die Methode Aktivieren(), die für alle Containerumschlag- 
geräte existieren muss, obgleich die eigentliche Implementierung abhängig 
vom konkreten Objekttyp ist und damit erst in der jeweiligen spezialisier- 
ten Klasse durchgeführt werden kann. Hiermit wird es möglich, Systemkom- 
ponenten zu implementieren, die lediglich „Kenntnis“ von der Schnittstelle 
der allgemeinen Klasse erfordern. Damit hat man die Möglichkeit, Syste- 
me über das spätere Hinzufügen spezialisierter Klassen zu erweitern (z. B. 
eines neuen Containerumschlaggerätes). In diesem Zusammenhang spricht 
man auch von einem polymorphen (verschiedenartigen) Verhalten von Ob- 
jekten, da ein Methodenaufruf in Abhängigkeit von der Klassenzugehörigkeit 
(kontextabhängig) eine Ausführung verschiedener Methoden nach sich ziehen 
kann. 

Die effektive praktische Anwendung objektorientierter Softwaretechni- 
ken lässt sich nicht auf einfache Regeln reduzieren, sondern setzt insbe- 
sondere entsprechende Erfahrungen voraus. Nichtsdestotrotz existieren hier 
heuristische Vorgehens weisen, die eine gewisse Hilfestellung geben können; 
vgl. z.B. Riel (1996). Es erscheint z. B. zweckmäßig, Klassen so autonom wie 
möglich zu konzipieren, damit einzelne Modifikationen und Erweiterungen 
des Entwurfes möglichst wenig weitere Modifikationen nach sich ziehen. Da 
beim objektorientierten Softwareentwurf verschiedene Probleme verbreitet 
auftreten, ist es - im Sinne des Wissensmanagements - zweckmäßig. Wissen 
über die Lösung solcher Probleme in geeigneter Form bereitzustellen. Hier- 
zu werden so genannte (Entwurfs-) Muster {Design Patterns) verwendet, die 
die abstrakte Beschreibung der Lösung allgemein auftretender Probleme in 

Aufgrund der Komplexität der objektorientierten Softwaretechnik verweisen wir 

als Grundlage auf Meyer (1997) sowie im Zusammenhang mit UML z.B. auf 

Booch et al. (2005), Jacobson et al. (1999), Balzert (2004) sowie Fowler (2004). 
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einem Kontext darstellen; vgl. Gamma et al. (1996) sowie Buschmann et al. 
(1998). 

Letztendlich kann man in Anlehnung an Meyer (1997) die objektorien- 
tierte Vorgehensweise primär als Methode zum Entwurf und zur Implemen- 
tierung der Systemarchitektur verstehen, die es Entwicklern erlaubt, leis- 
tungsfähige Systeme zu entwickeln, deren Struktur einfach und dezentral ist, 
was eine effiziente Erweiterbarkeit und Anpassbarkeit auch großer Systeme 
ermöglichen soll. In einem weitergehenden Sinne bietet die Objektorientie- 
rung insbesondere Potenziale für eine systematische Softwarewiederverwen- 
dung. 

6.4.2 Domain Engineering 

Die überwiegende Anzahl der Methoden zur Softwareentwicklung beziehen 
sich primär auf die Schaffung eines Anwendungssystems. Dagegen erscheint 
es offensichtlich, dass eine Wiederverwendung von Software im Rahmen eines 
allgemeinen Anwendungsbereiches {Domäne) eine systematische Auseinan- 
dersetzung mit den Konzepten der Domäne erfordert. Erst über einen sol- 
chen allgemeinen Ansatz ist es möglich, Gemeinsamkeiten und Variabilität 
von Konzepten einer Domäne zu erkennen und mittels adäquater Techni- 
ken in wiederverwendbare Software umzusetzen. Dies ist der Ausgangspunkt 
des Domain Engineering, das sich in einen wesentlichen Aufgabenbereich der 
Wirtschaftsinformatik einordnen lässt: der Entwicklung von Referenzmodel- 
len und Referenzarchitekturen. 

Die grundlegende Strukturierung des Domain Engineering in Aktivitäten 
und der Zusammenhang zum singulär ausgerichteten Entwicklungsprozess ist 
in Abbildung 6.5 skizziert. Die wesentlichen Phasen der Softwareentwicklung 
(Analyse, Entwurf, Implementierung) spielen sich hier auf zwei Ebenen ab: 
zum einen auf der auf die Domäne ausgerichteten Ebene des eigentlichen Do- 
main Engineering sowie zum anderen auf der speziell auf ein Anwendungssys- 
tem ausgerichteten Ebene des Application Engineering. Bei der Entwicklung 
konkreter Anwendungssysteme bedient man sich in allen Phasen wiederver- 
wendbarer Artefakte des Domain Engineering. 

Der in Abbildung 6.5 idealtypisch visualisierte Prozess verläuft in der 
praktischen Anwendung normalerweise nicht streng sequenziell, sondern in- 
krementell und iterativ. Die drei Phasen des Domain Engineering werden 
im Folgenden kurzgefasst charakterisiert. Während das Domain Engineering 
hierbei insbesondere im Rahmen der Domänenanalyse spezifische Methoden 
anbietet, stellt es ansonsten im Wesentlichen einen allgemeinen Rahmen dar, 
welcher adäquat auszufüllen ist (insbesondere auch unter Anwendung objekt- 
orientierter Vorgehensweisen).^^ 

Vgl. weiterführend zum Domain Engineering die Übersicht bei Czarnecki und 

Eisenecker (2000), Kapitel 2, sowie hinsichtlich spezieller Methoden z. B. Kang 

et al. (1990) sowie Simos et al. (1996). 
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Application Engineering 



Abbildung 6.5. Domain Engineering; in Anlehnung an CMU (2005a) 



Die Domänenanalyse als grundlegende Aktivität im Rahmen des Do- 
main Engineering erfordert die Akquisition von Wissen zu einer abgegrenz- 
ten Domäne. Die Domänenanalyse kann damit als Verallgemeinerung einer 
spezifischen Anforderungsanalyse (vgl. Abschnitt 6.1.2) aufgefasst werden. 
Inhalt der Domänenanalyse ist die Entwicklung eines Domänenmodells, in 
dem das relevante Wissen über eine Domäne systematisch abgebildet wird. 
Zweckmäßigerweise verwendet man als Grundlage hierfür u. a. vorhandene 
Anwendungssysteme der Domäne. Kern der Domänenanalyse ist die Ablei- 
tung von Gemeinsamkeiten und Variabilität in der Domäne. Unter Gemein- 
samkeiten einer Menge von Objekten werden die Merkmale verstanden, die 
für alle Objekte zutreffen, während Variabilität auftritt, wenn sich Objekte 
unterscheiden (z.B. hinsichtlich Struktur, Verhalten oder interner Mechanis- 
men). Mögliche Produkte der Domänenanalyse sind ein Domänenvokabular, 
Merkmalsdiagramme sowie semantische Spezifikationen der Domänenkonzep- 
te. 

Merkmalsdiagramme [Feature-Diagramme) stellen eine zweckmäßige, 
bezüglich einer späteren entwurfs- und implementierungstechnischen Umset- 
zung neutrale Form der Definition möglicher Systemausprägungen innerhalb 
einer Domäne dar. Unter Merkmalen werden hier jegliche signifikante System- 
bzw. Konzepteigenschaften verstanden. Im Rahmen von Merkmalsdiagram- 
men werden die Merkmale von Konzepten insbesondere klassifiziert in obli- 
gatorische, alternative und optionale Merkmale. Die Darstellung von Merk- 
malen ist in Abbildung 6.6 veranschaulicht. Kanten mit einem ausgefüllten 
oder offenen Kreis kennzeichnen obligatorische bzw. optionale Merkmale ei- 
nes Konzeptes oder Merkmales. Eine Menge von Merkmalen, aus denen genau 
oder maximal eines auszuwählen ist, wird durch einen Kreisbogen dargestellt; 
ein entsprechendes Merkmal bezeichnet man auch als Dimension. Merkma- 
le werden in der Regel textuell näher beschrieben (etwa hinsichtlich ihrer 
Semantik oder hinsichtlich des Zeitpunktes ihrer Festlegung). Gegebenen- 
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falls existieren Regeln, die die Menge zulässiger Merkmalskombinationen ein- 
schränken. Die zulässigen Merkmalskombinationen definieren mögliche Sys- 
temausprägungen für ein Merkmalsdiagramm. 




Abbildung 6.6. Beispiel für ein Merkmalsdiagramm 



Das Beispiel aus Abbildung 6.6 bezieht sich auf eine grobe, konzeptio- 
nelle Strukturierung möglicher Ausprägungen eines Dispositionssystems für 
die Abläufe auf Containerterminals. Obligatorisch für entsprechende Syste- 
me sind einerseits eine Datenbasis, in der z. B. Informationen zu Schiffsliege- 
plätzen und Containerstellplätzen abgebildet werden, sowie andererseits eine 
Planungsmethode, durch die Abläufe wie die Auswahl und der Transport von 
Containern disponiert werden. Hierbei wird unterschieden in exakte Metho- 
den und heuristische Methoden. Eine graphische Benutzeroberfläche wird als 
optional betrachtet. 

Während bei der Domänenanalyse das „Was?“ im Mittelpunkt steht, 
soll im Rahmen des Domänenentwurfes das grundsätzliche „Wie?“ beant- 
wortet werden. Dementsprechend besteht die Aufgabe in einer Umsetzung 
grundsätzlicher Konzepte und Merkmale der Domäne in eine generische Ar- 
chitektur, welche das grundsätzliche Zusammenwirken primärer Systemkom- 
ponenten bestimmt. Entsprechende Architekturen, die einen anzupassenden 
und zu vervollständigenden Rahmen sowie entsprechende Softwarekomponen- 
ten für Anwendungssysteme einer Domäne vorgeben, bezeichnet man auch 
als Frameworks}^ Entsprechend der im Domänenmodell abgebildeten Ge- 
meinsamkeiten und Variabilität besteht die wesentliche Schwierigkeit des 
Entwurfes in einer Abgrenzung der Betrachtung und Umsetzung von (po- 
tenziell variablen) Systemmerkmalen. Die Umsetzung dieser Abgrenzung ist 
problematisch, da in der Regel multidimensional variable Domänen mittels 
eindimensional ausgerichteter Mechanismen (etwa eine daten- oder funkti- 
onsorientierte Systemdekomposition) abgebildet werden müssen. 



13 



Vgl. Fayad et al. (1999). 
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Der Domänenentwurf und damit auch die Domänenimplementierung ba- 
sieren häufig auf der objektorientierten Vorgehensweise, da diese entspre- 
chende Mechanismen zur Abbildung von Gemeinsamkeiten und Variabilität 
bietet. Im Rahmen der Domänenimplementierung wird der Domänenent- 
wurf in wiederverwendbare Softwarekomponenten oder Generatoren umge- 
setzt. Unter Softwaregeneratoren versteht man hierbei Softwarewerkzeuge, 
die angepasste Software auf Basis einer primär deskriptiven Beschreibung 
(teil-)automatisiert erzeugen. 

6.4.3 Komponententechniken 

Unter Komponententechniken {Componentware) versteht man Konzepte zur 
komponentenorientierten Entwicklung offener Softwaresysteme; vgl. Griffel 
(1998) und Szyperski et al. (2002). Im Mittelpunkt stehen dabei Mechanis- 
men für das Zusammenwirken von Softwarekomponenten, die in verschie- 
denen Implementierungssprachen entwickelt wurden und gegebenenfalls ver- 
teilt (eventuell sogar auf verschiedenen Plattformen) ablaufen. Eine Software- 
komponente ist hierbei in der Regel ein direkt ausführbares Softwaremodul, 
was entsprechende Einschränkungen hinsichtlich der Anpassbarkeit nach sich 
zieht. Komponententechniken unterstützen die Entwicklung verteilter (de- 
zentraler) Systeme. Aufgrund der Komplexität solcher Systeme in der Praxis 
erscheint es geboten, Techniken einzusetzen, die eine systemübergreifende 
(Wieder-)Verwendung von Komponenten mit definierter Funktionalität er- 
lauben, um hiermit in strukturierter und inkrementeller Form leistungsfähige 
Informations- und Kommunikationssysteme zu entwickeln. 

Das Zusammenwirken von Softwarekomponenten bedingt in der Regel ein 
Erfüllen eines „Komponentenstandards“ mit definierten Interoperabilitäts- 
richtlinien. Dies kann heißen, dass die Schnittstellen entsprechender Kompo- 
nenten eine gewisse Mindestfunktionalität besitzen müssen (z. B. hinsichtlich 
des Zugriffes auf Informationen über die Komponente wie etwa Schnittstel- 
len und Parametrisierungsmöglichkeiten). Für derartige „Komponentenstan- 
dards“ gibt es verschiedene konkurrierende Ansätze, z.B. CORBA {Common 
Object Request Broker Architecture) , festgelegt von der Object Management 
Group (OMG (2005)), Enterprise JavaBeans sowie .NET von Microsoft. Sol- 
che Komponentenarchitekturen bzw. entsprechende Softwarelösungen, die die 
Integration verschiedener Softwarekomponenten oder -Systeme unterstützen, 
bezeichnet man auch als Middleware. In diesem Zusammenhang können auch 
die in Abschnitt 2.6.3 beschriebenen Web Services zum Einsatz kommen. Wei- 
terhin ist auf das auf Seite 36 angesprochene Scripting hinzuweisen, welches 
einen einfachen, prozedural orientierten Mechanismus zur Kombination von 
Komponenten darstellt; vgl. z.B. Nierstrasz und Lumpe (1997). 
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6.5 Übungen und Kontrollfragen 

1. Nennen Sie einen wesentlichen Vorteil der objektorientierten Software- 
entwicklung im Gegensatz zu konventionellen Verfahren? 

2. Nennen Sie grundlegende Aufgaben des Projektmanagements! 

3. Ihr Freund stellt Ihnen ein Informationssystem für die Niedersachsen- 
Radrundfahrt vor. Dabei fällt Ihnen als radsportinteressiertem Menschen 
auf, dass in diesem System innerhalb der Etappen keine Sprintwertun- 
gen an spezifischen Punkten abgebildet sind (so dass dadurch die Ver- 
gabe eines grünen Trikots unmöglich ist). Ihr Freund bittet Sie dar- 
um, den zusätzlichen Aufwand zur Implementierung dieser Funktiona- 
lität abzuschätzen. Sie beschließen, diese Aufwandsschätzung mittels des 
Function-Point-Verfahrens durchzuführen. Im Einzelnen bestehen folgen- 
de Anforderungen: 

i. Anlegen einer neuen Sprintwertung (Name der Etappe, Kilometeran- 
zahl vom Startpunkt der Etappe bis zum Ort der Sprintwertung) 
mit Eingabeüberprüfung, ob diese Sprintwertung bisher noch nicht 
erfasst wurde 

ii. Eingabe der Nummern und Namen der drei Erstplatzierten einer 
Sprintwertung 

iii. Eingabe der erhaltenen Punkte aus einer Sprintwertung bei den drei 
Erstplatzierten 

iv. Druckausgabe (in Listenform) der Sprintpunkte aller Fahrer (ein- 
schließlich Name, Nummer und Mannschaft des Fahrers), wobei nur 
diejenigen ausgegeben werden sollen, die mindestens einen Sprint- 
punkt gewonnen haben 

V. Online-Abfrage nach dem Namen, der Nummer und der Mannschaft 
des Fahrers mit den meisten Sprintpunkten (Besitzer des grünen Tri- 
kots) 

Ihre Aufgabe besteht somit aus drei Schritten: 

a) Ordnen Sie die oben beschriebenen Anforderungen jeweils einem der 
untenstehenden Funktionstypen zu und klassifizieren Sie sie nach 
den Kriterien einfach, mittel, komplex (mit kurzer Begründung)! 
Verwenden Sie dazu folgendes Muster: 
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Dateneingaben 


einfach 


mittel 


komplex 


Anzahl unterschiedlicher 
Datenelemente 


1-5 


6-10 


>10 


logische Datengruppen 


wenige 


mehrere 


viele 


Ansprnch an Bedienerführnng 


gering 


mittel 


hoch 


Eingabeprüfnng 


formal 


formal, 

logisch 


formal, logisch, 
Datenbankzugriff 


Gewicht 


3 


4 


6 



Datenausgaben 


einfach 


mittel 


komplex 


Medium 


Liste 


Liste 


Liste, Formular 


Anzahl der Listenspalten 


1-6 


7-15 


>15 


Gewicht 


4 


5 


7 



Datenabfragen 


einfach 


mittel 


komplex 


Anzahl unterschiedlicher Schlüssel 


1 


2 


>2 


Gewicht 


3 


4 


6 



b) Berechnen Sie auf Basis der Klassifizierung aus Teilaufgabe a) und 
des auf Erfahrungswerten basierenden Faktors der Einflussbewer- 
tung von 1,1 die bewerteten Function Points! 

c) Leiten sie anschließend anhand der unten angegebenen Erfah- 
rungswerttabelle aus den bewerteten Function Points (BFP) den 
geschätzten Aufwand in Personenständen (PS) ab! 



BFP 


PS 


BFP 


PS 


BFP 


PS 


BFP 


PS 






15 


14 


30 


26 


45 


39 


5 


6 


20 


18 


35 


30 


50 


43,5 


10 


10 


25 


22 


40 


34,5 







4. Der benötigte Projektaufwand für die Entwicklung eines Anwendungs- 
systems zur Unterstützung von Verwaltungsaufgaben an einem Uni- 
versitätsinstitut soll von Ihnen mittels des Function-Point-Verfahrens 
geschätzt werden. Der Einfachheit halber sollen bei der Ermittlung des 
funktionalen Umfanges der Anforderungen an das Anwendungssystem 
lediglich die Funktionstypen „Dateneingaben“, „Datenausgaben“ sowie 
„Datenabfragen“ behandelt werden. 

Die Zuordnung von Projektanforderungen zu diesen drei Arten von Funk- 
tionstypen und ihre Klassifizierung nach den Kriterien einfach, mittel, 
komplex soll nach dem Muster aus Aufgabe 3.a) erfolgen. 

Bei einer früheren vorläufigen Aufwandsschätzung ergab sich als Summe 
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aller nach ihrer Komplexität bewerteten Projekt anforderungen ein Wert 
von 437. Als Summe der Einflussfaktoren wurde ein Wert von 35 er- 
rechnet, woraus sich ein Faktor der Einflussbewertung von 1,05 ableitet. 
Als weitere Grundlage für die Berechnung des geschätzten Aufwandes in 
Personenmonaten (PM) ausgehend von den bewerteten Function Points 
(BFP) liegt die folgende Erfahrungswerttabelle vor: 



BFP 


PM 


BFP 


PM 


BFP 


PM 


BFP 


PM 






500 


33 


700 


49 


900 


65 


350 


21 


550 


37 


750 


53 


950 


70 


400 


25 


600 


41 


800 


57 


1000 


75 


450 


29 


650 


45 


850 


61 







Bei einer Überprüfung dieser Berechnungsgrundlagen stellen Sie fest, dass 

einige funktionale Anforderungen bisher nicht erfasst worden sind. Zu 

diesen Anforderungen zählen im Einzelnen: 

i. Anlegen eines neuen Studierendendatensatzes (Matrikelnummer, Na- 
mensdaten, Adressdaten) bei Anmeldung zu einer Klausur / Prüfung, 
falls der betreffende Student bzw. die Studentin bisher noch nicht er- 
fasst war 

ii. Eingabe einer Klausur-/Prüfungsnote in eine entsprechende Noten- 
liste 

iii. Druck-Ausgabe (in Listenform) der Noten aller Studierenden, die an 
einer bestimmten Klausur/Prüfung teilgenommen haben 

iv. Online- Abfrage nach der Adresse des Studenten bzw. der Studentin 
mit der besten Klausur-/Prüfungsnote 

Ihre Aufgabe besteht somit aus zwei Schritten: 

a) Ordnen Sie die oben beschriebenen Anforderungen jeweils einem 
Funktionstyp zu und klassifizieren Sie sie nach ihrem Gewicht 
(jeweils mit kurzer Begründung)! 

b) Berechnen Sie auf Basis der Klassifizierung aus a) die aktualisierte 
Summe der unbewerteten Function Points sowie mittels der bereits 
vorliegenden Summe der Einflussfaktoren bzw. des Faktors der Ein- 
flussbewertung die Summe der bewerteten Function Points! Leiten 
sie anschließend anhand der angegebenen Erfahrungswerttabelle den 
geschätzten Aufwand in Personenmonaten ab! 
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„No Systems, no impact!“ (Nievergelt (1994)) 

Unter einem Anwendungssystem kann man eine Menge von Program- 
men (und teilweise die dazugehörigen Daten) verstehen, die als Anwendungs- 
software für ein konkretes Anwendungsgebiet entwickelt, eingeführt und ein- 
gesetzt werden; vgl. Abschnitt 1.1. In diesem Kapitel werden überblicksar- 
tig einige Anwendungssysteme und zugehörige Einsatzgebiete sowie weitere 
Anwendungssysteme betreffende Themen, wie Architektur und Sicherheit, 
diskutiert. Dabei stehen betriebliche Anwendungssysteme im Vordergrund 
der Betrachtung, d. h. Systeme für konkrete betriebliche Anwendungsgebiete. 
Darüber hinaus werden einige Hinweise zu allgemeinen Anwendungssystemen 
gegeben, da diese z. B. im Rahmen einer Informationsbereitstellung ebenfalls 
betrieblichen Zwecken dienen können. 

Betriebliche Anwendungssysteme lassen sich aus verschiedenen Blickwin- 
keln betrachten. Wesentliche Komponenten sind dabei der Anwendungskern 
mit der fachlichen Logik, die Benutzerschnittstelle sowie die Datenverwal- 
tung. Während wir die letztgenannten Bereiche bereits kurz in den Kapi- 
teln 2 und 5 behandelt haben, betrachten wir hier vornehmlich die Anwen- 
dungen selbst, d. h. insbesondere das Umfeld einer geleisteten oder zu erbrin- 
genden Funktionalität sowie die eigentlichen fachbezogenen Funktionen, die 
zu erfüllen sind. 

In der Diskussion zu betrieblichen Anwendungssystemen nehmen unter- 
nehmensweite Systeme mit einer integrierten Informationsverarbeitung, die 
verschiedene Unternehmensbereiche miteinander verbindet, eine exponier- 
te Stellung ein. In diesem Zusammenhang hat sich der Begriff Enterprise 
Resource Flanning (ERP) etabliert; unter ERP-Systemen versteht man be- 
triebswirtschaftliche Anwendungssyteme für die integrierte Informationsver- 
arbeitung. Derartige Software beinhaltet in der Regel mehrere Komponenten 
für verschiedene Anwendungsaufgaben (Personal, Finanzen, Rechnungswe- 
sen, Logistik, Transport, Produktionsplanung usw.). Oftmals sind zusätz- 
lich branchenspezifische Komponenten bzw. Lösungen vorhanden. Eine Da- 
tenbank für die unternehmensinternen Daten, die im ERP-System genutzt 
werden, ist meist integriert; darüber hinaus existiert jedoch in der Regel 
auch die Möglichkeit zur Anbindung weiterer (externer) Datenbanken. ERP- 
Standardsoftware gibt es von diversen Herstellern, z.B. Microsoft, Oracle 
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und SAP, wobei das letztere Unternehmen weltweit Marktführer für derarti- 
ge Systeme für mittlere und große Unternehmen ist. 

Bei Verwendung von ERP-Standardsoftware ist für speziellere Aufgaben 
häufig eine Anbindung externer Software(-Komponenten) bzw. Anwendungs- 
systeme notwendig. Eine solche Anbindung kann dadurch ermöglicht werden, 
dass entsprechende Schnittstellen im ERP-System vorhanden sind. Diese wer- 
den insbesondere für die Datenübertragung zwischen dem ERP-System und 
der externen Software benötigt. Eine weitere Folge der Standardisierung be- 
trieblicher Abläufe innerhalb der ERP-Systeme ist die Notwendigkeit der 
Anpassung des Systems an die jeweiligen Anforderungen und Rahmenbedin- 
gungen eines Unternehmens. Dieser Prozess wird mit Customizing bezeich- 
net und kann einen sehr hohen Aufwand beinhalten. Da für das Customizing 
tiefergehende Kenntnisse des betreffenden ERP-Systems Voraussetzung sind, 
wird hierfür in der Regel ein entsprechender Dienstleister verpflichtet. 

Vorteile von ERP-Systemen sind u. a. die Integration vieler oder so- 
gar aller Geschäftsvorgänge, folglich eine einheitliche Benutzeroberfläche für 
die entsprechenden Aufgaben und eine Vermeidung (bzw. Verringerung) 
der Notwendigkeit zur Anpassung mehrerer Anwendungssysteme aneinander. 
Darüber hinaus kann der Datenaustausch mit Geschäftspartnern (Lieferan- 
ten, Kunden), die nicht notwendigerweise das gleiche ERP-System verwen- 
den, verbessert werden. In jüngerer Zeit findet darüber hinaus eine (gege- 
benenfalls unternehmensübergreifende) Unterstützung so genannter Supply 
Chains (Lieferketten) und deren Management statt. 

Neben den für Standardsoftware üblichen Nachteilen (wie Abhängigkeit 
von einem Softwareanbieter und Notwendigkeit der Anpassung der Software 
an die betriebliche Umgebung) besitzt ERP-Standardsoftware den Nachteil, 
dass durch das notwendige, oftmals sehr umfangreiche Customizing der ei- 
gentlich bestehende Kostenvorteil gegenüber Individualsoftware zunichte ge- 
macht werden kann. Des Weiteren ist durch die Vielfalt der im System ab- 
gebildeten Aufgaben und die gewünschte Breite an Anwendungsmöglichkei- 
ten für spezielle Aufgaben nicht immer eine geeignete Problemlösungskom- 
ponente im ERP-System integriert, was zusätzliche (Spezial-)Software er- 
zwingt. Insbesondere ist die Planungsfunktionalität in ERP-Systemen häufig 
ungenügend. 

Im Folgenden diskutieren wir zunächst einige grundlegende Überlegungen 
zu Anwendungssystemen und deren Einsatz. Daran anschließend beschrei- 
ben wir exemplarisch einige Anwendungssysteme bzw. die ihnen zu Grunde 
liegenden Funktionalitätsanforderungen sowohl in der Industrie als auch im 
Dienstleistungsbereich, und hier speziell im Verkehrsbereich. Obwohl sich eine 
Vielzahl an Branchen unter die Bereiche Industrie und Dienstleistung subsu- 
mieren lassen, sind auch übergreifende Anwendungssysteme vorzufinden, so 
dass wir hier insbesondere das Themengebiet Electronic Commerce in einem 
separaten Abschnitt behandeln. 
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7.1 Grundlagen 

Anwendungssysteme lassen sich grundsätzlich nach ihrem Verwendungszweck 
insbesondere in Administrations- und Dispositionssysteme sowie Planungs- 
und Kontrollsysteme unterscheiden.^ In Erweiterung von Abbildung 1.1 (S. 4) 
zeigt Abbildung 7.1 wesentliche Funktionsbereiche eines Unternehmens so- 
wie Integrationsrichtungen hinsichtlich dieser verschiedenen Anwendungssys- 
teme. 




Abbildung T.l. Anwendungssystemübersicht; vgl. z. B. Mertens (2004) 



Hinsichtlich der Differenzierung der einzelnen Anwendungssysteme spielt 
insbesondere die Art der Einbeziehung von Fragen der Entscheidungsvor- 
bereitung und der Entscheidungsunterstützung eine Rolle. So dienen Admi- 
nistrationssysteme im Wesentlichen der Datenverwaltung bei routinemäßigen 
Aufgaben mit großen Datenvolumina. Kommt zur Datenverwaltung eine au- 

^ Vgl. z.B. Mertens (2004) und Mertens und Griese (2002), bei denen 
Administrations- und Dispositionssysteme auch als Operative Systeme bezeich- 
net werden. Des Weiteren werden in der Literatur Planungs- und Kontrollsysteme 
auch unter dem Begriff Führungssysteme zusammengefasst; vgl. z. B. Stahlknecht 
und Hasenkamp (2005). 
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tomatisierte Entscheidungsvorbereitung hinzu, so spricht man von Disposi- 
tionssystemen. Eine um Interaktionsmöglichkeiten erweiterte Entscheidungs- 
vorbereitung innerhalb eines Dispositionssystems mit planerischem Charak- 
ter auf Sach- oder Einzelfallebene führt zu einem Planungssystem. Die Über- 
wachung der Planeinhaltung erfolgt mit Hilfe von Kontrollsystemen. Hinsicht- 
lich der Entscheidungsvorbereitung und -Unterstützung am weitesten reichen 
Management-Support-Systeme, Entscheidungsunterstützungssysteme sowie 
wissensbasierte Systeme; vgl. Abschnitt 3.4. 

Neben den genannten Systemen stellen Querschnittssysteme solche Sys- 
teme dar, die unabhängig von einer spezifischen Einordnung in bestimm- 
te Unternehmensbereiche bzw. Hierarchiestufen sind sowie gegebenenfalls in 
Verbindung mit anderen Systemen genutzt werden. Zu den Querschnittssys- 
temen gehören insbesondere Bürosysteme, Dokumentenmanagementsysteme 
und Workflow-Management-Systeme. 

Als Beispiele für insbesondere branchenunabhängige Anwendungsgebie- 
te und -Systeme seien exemplarisch die Folgenden genannt. Im Finanzwesen 
bietet sich eine Computerunterstützung z. B. für die Finanz- und Liquiditäts- 
disposition (d.h. die Vorhersage von Einnahme- und Ausgabeströmen sowie 
Entscheidungen über die Anlage freier Mittel oder die Aufnahme von Kredi- 
ten), für die Prognose von Massenzahlungen und die simultane Finanz- und 
Investitionsprogrammplanung an. 

Das Personal wesen kann hinsichtlich der Arbeitszeit Verwaltung sowie der 
Entgeltabrechnung durch Anwendungssysteme unterstützt werden. Daneben 
gibt es aber auch Meldeprogramme oder Veranlassungsprogramme, die Ver- 
anlassungen kurz vor Fälligkeit von Maßnahmen ausgeben; als einfaches Bei- 
spiel sei die Veranlassung spezieller Gratifikationen im Falle von Jubiläen 
genannt. 

Eine sehr intensive Nutzung von Anwendungssystemen findet im Rech- 
nungswesen statt, da hier große Mengen gut strukturierter Daten verarbeitet 
werden müssen. Dabei kann eine Unterteilung in Kosten- und Leistungsrech- 
nung, Hauptbuchhaltung sowie Nebenbuchhaltung (Debitorenbuchhaltung, 
Kreditorenbuchhaltung) erfolgen. 

Auch wenn es in der Wirtschaft viele Einsatzmöglichkeiten für Anwen- 
dungssoftware gibt, werden diese nicht überall in vollem Maße ausgenutzt. 
Ein Grund hierfür ist die Tatsache, dass zu Beginn der Informationsverarbei- 
tung in Unternehmen oftmals nur ausgewählte Teilbereiche durch Software 
unterstützt wurden. Hierfür wurden spezielle Softwarelösungen verwendet, 
die zum Teil individuell auf die Situation im Unternehmen zugeschnitten 
wurden. Eine Erweiterung dieser Systeme bzw. eine Anbindung anderer An- 
wendungssoftware ist dadurch erschwert. Eine strategisch ausgerichtete Op- 
tion zur Überwindung dieser Probleme ist der Einsatz von ERP-Systemen. 
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7.1.1 Architektur und Integration von Anwendungssystemen 

Anwendungssoftware unterstützt in der Regel nur einen begrenzten Aufga- 
benbereich. Aus diesem Grund ist häufig eine Kopplung oder Integration un- 
terschiedlicher Software zu einem ERP-System (bzw. die Erweiterung beste- 
hender Systeme) für eine aufgabenübergreifende Unterstützung erforderlich. 
Um Anwendungssoftware geeignet integrieren und erweitern zu können, ist 
eine zweckmäßige Softwarearchitektur von erheblicher Relevanz. Unter Soft- 
warearchitektur versteht man den planmäßigen Aufbau von Software (-Sys- 
temen), d. h. die Bildung und Anordnung von Systemelementen und ihren 
Beziehungen. Um die Komplexität von Anwendungssystemen zu bewältigen, 
erfolgt grundlegend eine Modularisierung. Hierbei werden kleinere Einheiten 
definiert, die über Schnittstellen miteinander kommunizieren und Zusammen- 
arbeiten; vgl. hierzu auch die in Abschnitt 6.4.1 betrachtete objektorientierte 
Softwaretechnik. 

Bei der Kopplung von Anwendungssystemen kann man grob in eine daten- 
orientierte und eine nachrichtem/ereignisorientierte Kopplung unterscheiden. 
Die datenorientierte Kopplung zeichnet sich dadurch aus, dass entsprechende 
Anwendungssysteme die gleiche Datenbasis nutzen, die jedoch auch verteilt 
oder sogar redundant aufgebaut sein kann. Bei der nachrichtem/ereignis- 
orientierten Kopplung interagieren Anwendungssysteme durch den direkten 
Austausch von Nachrichten (etwa im Sinne eines Methodenaufrufs); vgl. auch 
Abschnitt 6.4.3 sowie die dort erwähnte Middleware. 

Aufgrund der heute weitgehend vorhandenen leistungsfähigen Rechner- 
netze ist eine räumliche Aufteilung von Anwendungssystemen und entspre- 
chenden Komponenten auf verschiedene Rechner möglich. Ein Beispiel für 
eine derartige Verteilung ist die in Abschnitt 2.5.1 vorgestellte Client-Server- 
Architektur, bei der auf Servern bestimmte Dienste bereitgestellt werden, 
auf die Clients zugreifen. In diesem Zusammenhang können auch Weh Ser- 
vices zum Einsatz kommen; vgl. Abschnitt 2.6.3. Im Idealfall können somit 
Anwendungssysteme aus diversen verteilt vorliegenden, gekapselten Diensten 
ad hoc zusammengesetzt werden. Diese Vorstellung ist mit der so genann- 
ten serviceorientierten Architektur (SOA, Service-Oriented Architecture) ver- 
bunden; vgl. Erl (2004). Dieses Architekturmodell zeichnet sich demzufolge 
dadurch aus, dass bei der Gestaltung von Anwendungssystemen eine Modu- 
larisierung der Funktionalität des Systems in einzelne Dienste stattfindet, die 
jeweils eng umgrenzte Funktionen abbilden und über wohldefinierte Schnitt- 
stellen miteinander interagieren. 

Eine wesentliche Eigenschaft von ERP-Systemen ist die Integration meh- 
rerer Programme zu einem umfassenden System, das verschiedene Funktions- 
bereiche abdeckt. Unter Integration ist dabei auch eine ebenenübergreifende 
Verknüpfung zu verstehen, die auch die geeignete Interaktion von Mensch und 
Technik berücksichtigt. In der Pyramide in Abbildung 7.1 sind hinsichtlich 
der Integrationsrichtung im Wesentlichen die horizontale und die vertikale 
Integration unterschieden. Eine Übersicht über verschiedene Formen der In- 
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tegration, nach der sich auch Anwendungssysteme klassifizieren lassen, gibt 
Tabelle 7.1; vgl. z.B. Mertens (2004). 



Integrations- 

dimension 


Inhalt 


Objekte 


Datenintegration (logische Zusammenführung von Daten) 


Funktionsintegration (Aufgabenabstimmung, informati- 
onstechnische Verknüpfung von an Objekten durch- 
zuführenden Verrichtungen) 


Prozess- und Aktivitätsintegration (Verbindung von 
(Geschäfts-)Prozessen entlang sachlogischer Reihenfolgebe- 
ziehungen) 


Methodenintegration (Abstimmung von Methoden und 
Verfahren) 


Programmintegration (Abstimmung verschiedener Softwa- 
rekomponenten oder Programme) 


Organisationsintegration (Verknüpfung über aufbauorgani- 
satorische Grenzen hinweg) 


Orientierung 


Horizontale Integration (Verbindung von Teilsystemen ent- 
lang der betrieblichen Wertschöpfungskette) 


Vertikale Integration (Verbindung von Administrations- 
und Dispositionssystemen mit Planungs- und Kontrollsys- 
temen) 


Reichweite 

(organisatorisch) 


Bereichsintegration (Daten-, Funktions- und Prozessinte- 
gration, z. B. bezogen auf Workflows) 


Innerbetriebliche Integration (unternehmensinterne Inte- 
gration) 


Zwischenbetriebliche Integration (Integration über Unter- 
nehmensgrenzen hinweg; Integration innerhalb von Unter- 
nehmensnetzwerken und virtuellen Organisationen) 


Reichweite 

(zeitlich) 


Intertemporale Integration (repetitive Verknüpfung von 
Entscheidungsprozessen verschiedener Fristigkeit) 


Automationsgrad 


Vollautomation (Funktionalitätserfüllung ohne menschli- 
ches Eingreifen) 


Teilautomation (Interaktionsunterstützung zwischen 

Mensch und Technik) 



Tabelle 7.1. Integrationsformen 



Die verschiedenen Integrationsdimensionen spielen insbesondere in der 
Unternehmensmodellierung eine wesentliche Rolle; vgl. Abschnitt 4.1.1. Da- 
bei sollte die Differenzierung der Integrationsformen nicht dogmatisch ge- 
handhabt werden, sondern die Möglichkeit bestehen, z. B. verschiedene 
Geschäftsprozesse im Zuge der Prozessintegration geeignet gekoppelt mit der 
Organisationsintegration auch über Bereichsgrenzen hinweg zu definieren. 
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Als vertikale Integration gilt die Verbindung von Administrations- und 
Dispositionssystemen mit Planungs- und Kontrollsystemen. Dies betrifft im 
Wesentlichen die Datenversorgung der letztgenannten Systeme durch die erst- 
genannten. In erweitertem Sinne können wir hier hinsichtlich einer umfassen- 
den Transaktionsdatenverfügbarkeit versus einer Planungs- und Analysefunk- 
tionalität differenzieren. 

Während sich für die meisten ERP-Systeme in der Praxis eine hervorra- 
gende Transaktionsdatenverfügbarkeit konstatieren lässt, gilt dies hinsichtlich 
der Planungsfunktionalität eher weniger. Obwohl oftmals gute Verfahren des 
Operations Research sowie mathematische Methoden in entsprechende Sys- 
teme integriert sind, fehlt es insbesondere an der geeigneten Unterstützung 
bei der (mathematischen) Modellierung realer Probleme. Demzufolge ist bei 
dem Einsatz und der (Methoden-)Integration entsprechender Verfahren stets 
darauf zu achten, dass die zu lösenden Probleme adäquat modelliert sind.^ Im 
Zuge der zeitlichen Reichweite der Integration sind hierbei auch strategische 
Fragen auf Basis verfügbarer Transaktionsdaten aus Administrations- und 
Dispositionssystemen im Sinne von Planungsfunktionalität in regelmäßigen 
Abständen zu überdenken. 



7.1.2 Standardsoftware 

Eine wesentliche Frage im Zusammenhang mit Anwendungssystemen be- 
trifft das „Make or Buy“, d.h. die Entscheidung hinsichtlich der Verwen- 
dung von Individualsoftware oder Standardsoftware. Während Individualsoft- 
ware Anwendungssysteme und Programme umfasst, die für einen spezifischen 
Anwendungsfall erstellt werden, bezeichnet Standardsoftware Systeme oder 
Programme, die auf Allgemeingültigkeit und Mehrfachverwendung ausgelegt 
sind. 

Bei der Entscheidung über den Einsatz einer Individualsoftware ist im 
Wesentlichen zu eruieren, ob die Software selbst entwickelt wird oder aber 
im Rahmen einer Fremd vergäbe von einem Dienstleister extern erstellt wird.^ 
In beiden Fällen erlaubt Individualsoftware auf Basis einer detaillierten Pla- 
nung und Anforderungsanalyse hinsichtlich zu erfüllender Funktionalität eine 

^ Praktische Erfahrungen veranlassen uns, in diesem Zusammenhang explizit da- 
rauf hinzuweisen, dass die Begriffe „optimal“ und „Optimum“ wohldefiniert und 
nicht steigerungsfähig sind. 

® Vgl. zur Eigenentwicklung insbesondere das Thema Softwareentwicklung in Ka- 
pitel 6. Hinsichtlich der Fremdvergabe wird häufig der Begriff Outsourcing 
{Outside Kesourcing) verwendet. Zu einer kurzen Übersicht zum Outsourcing 
vgl. neben Abschnitt 3.6 z.B. Schwarze (1998) sowie Voß und Gutenschwager 
(2001). In einem modifizierten Kontext stellt sich darüber hinaus die Frage nach 
dem Einsatz eines Anwendungssystems. Neben dem Erwerb eines Systems kann 
dabei auch die Anmietung dergestalt in Erwägung gezogen werden, dass gegen 
Gebühren über Rechnernetze auf das System zugegriffen werden kann. Dienst- 
leister in diesem Sinne werden auch als Application Service Provider bezeichnet. 
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individuelle Anpassung sowohl an unternehmensspezifische als auch an auf- 
gabenspezifische Gegebenheiten. 

Standardsoftware umfasst insbesondere Anwendungssysteme für spezielle 
Bereiche (z. B. Systeme für die Produktionsplanung und -Steuerung oder Fi- 
nanzbuchhaltungssoftware), wobei diese Bereiche bestimmte Unternehmens- 
funktionen, aber auch branchenspezifische Aspekte umfassen können. Als 
Beispiel sei die Produktionsplanung für die Automobilindustrie gegenüber 
der Stahlindustrie genannt. Vereinfacht ausgedrückt erfolgt im ersten Fall im 
Wesentlichen die Zusammenführung verschiedenster Komponenten zu einem 
Produkt (dem Auto); im zweiten Fall wird ausgehend von einem Rohstoff 
eine vielfältige Palette an Produkten gefertigt. 

Neben bereichs- oder branchenspezifischen Anwendungssystemen wie 
z.B. Finanzbuchhaltungssoftware werden als Standardsoftware insbesonde- 
re Komplettpakete unter der Bezeichnung ERP-Software verstanden. Dabei 
handelt es sich vornehmlich um unternehmensweite Lösungen, die insbeson- 
dere durch größere Softwarehäuser angeboten werden. Darüber hinaus sind 
im Bereich der Standardsoftware universell verbreitete funktionsübergreifen- 
de Pakete für Textverarbeitung, Tabellenkalkulation, Graphikbearbeitung so- 
wie eventuell einfache Datenverwaltung (Office-Pakete) vorzufinden. 

Neben der am Markt erhältlichen Standardsoftware steht gegebenenfalls 
auch kostenfreie Public-Domain-Software zur Verfügung, die jedoch in der 
Regel keine so weit reichenden Anforderungen wie z. B. die in ERP-Systemen 
gegebene Transaktionsdatenverfügbarkeit erfüllt, sondern eher auf speziel- 
le Aufgaben abzielt. Probleme bereiten in diesem Fall jedoch oftmals nicht 
vorhandene Garantien hinsichtlich Qualitätssicherung und Wartung. 

Standardsoftware ist meistens auf unternehmensspezifische Gegebenhei- 
ten anzupassen (Gustomizing). Sofern alle Funktionalitätsanforderungen 
durch das Setzen von Parametern („Schalter umlegen“) erfüllbar sind, spricht 
man von Parametrisierung. Im Regelfall wird jedoch eine weiter gehende 
Konfigurierung angebracht sein, d. h. eine Modularisierung dergestalt, dass 
gewünschte Module übernommen und um neu entwickelte Module ergänzt 
werden; vgl. auch Abschnitt 6.4. Darüber hinaus kann eine Individualpro- 
grammierung erforderlich sein, um die Standardsoftware in ein gegebenes 
Unternehmensumfeld einbinden zu können. Zur Anpassung an bestimmte 
Bereiche oder Branchen liegen gegebenenfalls Referenzmodelle vor, die ins- 
besondere ein Vorgehensmodell für das Gustomizing integrieren. 

Eine sorgfältige Abwägung der Vor- und Nachteile von Standardsoft- 
ware gegenüber Individualsoftware betrifft insbesondere die Frage der Ge- 
nauigkeit der Aufgabenerfüllung sowie den damit verbundenen Gustomizing- 
Tätigkeiten. Wesentliche Vorteile einer Standardsoftware können eine kürze- 
re Einführungszeit sowie geringere Kosten sein, und es braucht kein Personal 
für die Softwareentwicklung vorgehalten zu werden. Demgegenüber können 
notwendige Anpassungen sowohl in der Aufbau- als auch in der Ablauforga- 
nisation eines Unternehmens (verbunden mit den Ghancen, die eine Reorga- 
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nisation von Geschäftsprozessen bieten kann) erforderlich sein. Man beachte 
in Verbindung mit dem Einsatz von Standardsoftware demzufolge auch ei- 
ne sich möglicherweise ergebende Einschränkung hinsichtlich der Flexibilität 
interner Unternehmensabläufe. Auf der anderen Seite ergibt sich durch die 
Nutzung von Standardsoftware gegebenenfalls eine Vereinfachung der zwi- 
schenbetrieblichen Integration der IV (so genannte Netzeffekte). 

Aufgrund vorhandenen Overheads von Standardsoftware sind die Rechen- 
zeiten bzw. das Antwortzeit verhalten in manchen Fällen deutlich höher als 
bei Individualsoftware. Weitere Aspekte, die im Vergleich abzuwägen sind, 
betreffen z.B. die Schnittstellenproblematik hinsichtlich der Anbindung an 
andere Systeme oder Schulungsmaßnahmen. 

7.1.3 Front Office versus Back Office 

Ausgehend von der Unterscheidung, inwiefern Anwendungssysteme im di- 
rekten Kundenkontakt genutzt werden oder nicht, lassen sich so genannte 
Front-Ofhce-Systeme und Back-Office-Systeme unterscheiden. Im Informa- 
tionsmanagement kann man dazu analog zwischen einem externen und ei- 
nem internen Informationsmanagement unterscheiden. Vereinfacht differen- 
zieren wir zwischen Systemen, die unternehmensintern im Zuge der Planung, 
Durchführung und Kontrolle der Leistungserstellung genutzt werden (Back 
Office), und solchen, die in unmittelbarem Kontakt mit einem (End-)Kunden 
stehen (Front Office). 

In Abbildung 7.2 wird eine Basisarchitektur für Anwendungssysteme ins- 
besondere im Dienstleistungsbereich vorgestellt. Die einzelnen Komponenten 
(Zugangssysteme, Transaktionssysteme usw.) können als Anwendungssyste- 
me aufgefasst werden, die jeweils Teilaufgaben des gesamten Systems über- 
nehmen. 

Zugangssysteme dienen dazu, einem Kunden den Zugang zu weiteren 
Anwendungssystemen zu ermöglichen. Hierzu gehören das Herstellen einer 
Verbindung vom Endgerät, von dem aus der Kunde einen Zugang erhal- 
ten möchte (z.B. PC, Selbstbedienungsterminal oder Mobiltelefon), und 
die Authentifikation des Kunden. Letzteres ist durch die Verwendung von 
Passwörtern, Kennnummern, Ausweiskarten (z.B. Chipkarten) o. A. möglich. 
Anschließend kann der Kunde Systeme zur Informationsheschaffung nutzen, 
um sich insbesondere zu Produkten mit hohem Erklärungsbedarf informie- 
ren und beraten zu lassen. Dies kann sowohl den Abruf von Angebots- und 
Leistungsdaten, aber auch zusätzliche Hilfestellung durch Experten- oder wis- 
sensbasierte Systeme umfassen. Präsentationssysteme stellen diese Informa- 
tionen geeignet dar und bilden somit die Schnittstelle zwischen dem Anwen- 
dungssystem und dem Kunden. 

Transaktionssysteme sind sowohl im Back-Office- als auch im Front-Office- 
Bereich anzutreffen. In beiden Fällen soll mit ihrer Hilfe die Abwicklung 
von formalisierten und meist kurzen Verarbeitungsvorgängen in einem vorge- 
planten Dialog ermöglicht werden, wobei sich nur Eingabeparameter ändern. 
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Abbildung 7.2. Front-Office- und Back-Office-Systeme; in Anlehnung an Mertens 
et al. (2000) 



Ein Beispiel hierfür wäre eine Platzreservierung, bei der nach Eingabe der 
gewünschten (Flug-, Bahn- oder Bus-)Verbindung und gegebenenfalls an- 
derer Eingabeparameter, wie Raucher/Nichtraucher oder Fensterplatz, eine 
entsprechende Transaktion (Reservierung) automatisiert vorgenommen wird. 
Darüber hinaus können derartige Systeme auch zur Bezahlung von Leistun- 
gen genutzt werden. Im Front-Office-Bereich dienen Transaktionssysteme so- 
mit der Leistungsvereinbarung und z.T. auch der Nachbehandlung (z.B. in 
Form einer Reklamationsannahme). 

Dokumentenmanagementsysteme (DMS) werden zur Speicherung, Ver- 
waltung und Wiedergewinnung von Dokumenten in elektronischer Form ver- 
wendet. Insbesondere unformatierte Datenbestände in Form diverser Doku- 
mente (Briefe, Texte, Bilder usw.) können hiermit unternehmensweit organi- 
siert und verwaltet werden. Ein Dokument fasst dabei inhaltlich zusammen- 
gehörige Informationen zusammen. Dokumentenmanagement lässt sich somit 
als effiziente (wirtschaftliche) Verwaltung - auch im Sinne der Gestaltung 
eines Rahmenkonzeptes zur Erstellung von Dokumenten -, Beschaffung, Al- 
lokation und Distribution von Dokumenten als Ressource zur Unterstützung 
von Geschäfts- und Entscheidungsprozessen auffassen. Das Dokumentenma- 
nagement bildet damit einen integralen Teil des Informationsmanagements, 
wobei Fragestellungen der Informationslogistik in diesem Bereich besondere 
Bedeutung zukommt; vgl. Voß und Gutenschwager (2001). 

Eine eindeutige Trennung zwischen DMS und Systemen zur Un- 
terstützung von Geschäftsprozessen (Workflow-Management-Systeme) so- 
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wie Systemen zur Unterstützung von Gruppenarbeit (Groupware) ist nicht 
möglich. So können entsprechende DMS-Funktionalitäten z. B. dazu dienen, 
die einem Groupware-System zu Grunde liegende Informationsbasis zu ver- 
walten. Vielmehr ist ein Zusammenwachsen der Bereiche Groupware und Do- 
kumentenmanagement unter einheitlichen Kommunikationsplattformen (In- 
tranets) zu konstatieren. 

7.1.4 Workflow-Management-Systeme und Groupware 

Work flow- Management- Systeme (WMS) dienen der Unterstützung der Vor- 
gangssteuerung, d. h. der Steuerung des Arbeitsablaufes zwischen allen an 
der Bearbeitung eines Geschäftsprozesses beteiligten Parteien (z.B. Perso- 
nen oder Gomputer). Ziele sind die Definition, Koordination und Steuerung 
der Geschäftsprozesse in Unternehmen, die Reduzierung von Medienbrüchen 
(Papier, Gomputer, verschiedene Datenformate) sowie die Reduzierung von 
Durchlauf- und Bearbeitungszeiten. ^ 

Grundlage für WMS ist das Workflow-Konzept. Hierbei werden zuerst 
Prozesse in Arbeitsschritte bzw. Aktivitäten (gegebenenfalls einschließlich 
der Definition notwendiger Reihenfolgebeziehungen) unterteilt und diese im 
WMS modelliert. Da gewisse Arbeitsschritte häufig auftreten (können), brau- 
chen diese nur einmal modelliert zu werden und können dann in nachfolgen- 
den Prozessen wiederverwendet werden.^ Die Modellierung von Geschäftspro- 
zessen im WMS geschieht anschließend durch Zusammensetzen der Prozesse 
aus den modellierten Aktivitäten. Hierbei müssen ebenso die Beziehungen 
zwischen den Aktivitäten modelliert werden. 

Wichtige Funktionen von Workflow-Management-Systemen sind: 

• Vorgangsgenerierung: Auswahl und Auslösung eines aufgabenadäquaten 
Vorgangstyps, 

• Vorgangsorganisation und -Steuerung: Zerlegung von Vorgängen in Ele- 
mentartätigkeiten, Anstoß der durchführbaren Vorgangsschritte, gegebe- 
nenfalls Beschaffung der dazu nötigen Informationen und Weiterleitung 
des Vorganges, 

• Vorgangsinformation und -Verfolgung: Bereitstellung von Informationen 
über den Stand der Vorgangsbearbeitung und Terminüberwachung, 

• Vorgangsterminierung: Beendigung des Vorganges, gegebenenfalls Zusam- 
menführung von Teilergebnissen zum Gesamtergebnis. 

WMS lassen sich in Push- und Pull-Systeme unterscheiden. Bei Push- 
Systemen werden dem Nutzer für zu bearbeitende Vorgänge die notwendigen 
Aufgaben einschließlich der zugehörigen Daten, Informationen, Dokumente 

Vgl. zu WMS z.B. Vossen und Becker (1996), Leymann und Roller (2000), van 
der Aalst und van Hee (2002) sowie Richter- von Hagen und Stucky (2004). 

® Grundlage dieser prozessorientieren Modellierung können beispielsweise die in 
Abschnitt 4.4 vorgestellten Methoden sein. 
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und Applikationen übergeben. Bei Pull-Systemen muss sich der Nutzer diese 
selbst beschaffen bzw. die Beschaffung selbst anstoßen, benötigte Applikatio- 
nen auswählen und den Fortgang der Vorgangsbearbeitung festlegen. 

Workffow Management als Gestaltung von Arbeitsflüssen bzw. 
Geschäftsprozessen gilt auch der Unterstützung von Gruppen. Vor- 
nehmlich kommen hier jedoch Groupware-Systeme zum Einsatz. Ziel 
derartiger Systeme ist es, disloziert tätigen Personen eine Zusammenarbeit 
zu ermöglichen. 

Groupware-Plattformen wie beispielsweise Lotus Notes lassen sich als all- 
gemeine Software für die Unterstützung von (Arbeits-) Gruppen auffassen und 
stellen somit Anwendungssysteme dar, die nicht ausschließlich dem betriebli- 
chen Bereich zuzuordnen sind. Zu den grundlegenden Funktionalitäten einer 
Groupware-Plattform gehören integrierte E-Mail-, Kalender- und Terminpla- 
nungsfunktionen, Replikationsmechanismen, Möglichkeiten für den Im- und 
Export von Daten, Informationen und Dokumenten sowie Retrievalfunktiona- 
lität. Unter Replikation verstehen wir dabei die Verteilung und den Abgleich 
der in einem (gegebenenfalls virtuellen) Netzwerk verteilt angelegten Kopien 
von Dokumenten. 

Neben den genannten Funktionalitäten in Anwendungssystemen zur Un- 
terstützung von Gruppenarbeit werden unter dem Thema Groupware auch 
verteilt vorliegende Informations- und Kommunikationstechnologien, wie sie 
z. B. in Form von Videokonferenzsystemen vorzufinden sind, verstanden.® We- 
sentliche Systeme umfassen darüber hinaus die Unterstützung von Gruppen- 
entscheidungen im Zuge so genannter Group-Decision-Support-Systeme. 



7.2 Sicherheit von Anwendungssystemen und 
Kommunikationsnetzen 

Die breite Verfügbarkeit von Rechnernetzen bzw. des Internets und die Ab- 
wicklung sowohl von Geschäftsverkehr als auch privater Kommunikation auf 
dieser Basis beinhalten die Übertragung von Daten zwischen in der Re- 
gel nicht lokalen Informationssystemen. Durch die Zunahme von verteilten 
Anwendungssystemen (z. B. in Form von Glient-Server-Systemen oder Web 
Services) nimmt ebenfalls die Kommunikation zwischen verschiedenen An- 
wendungssystemkomponenten auf Basis von Rechnernetzen zu. Solche Da- 
tenübertragungen müssen ebenso wie die (verteilten) Anwendungssysteme 
und die ihnen zugrunde liegende Hardware (Rechner) häufig gewissen Bedin- 
gungen genügen bzw. bestimmte Voraussetzungen erfüllen. Wichtige mögliche 
Anforderungen sind; vgl. z.B. Schäfer (2003): 



Im Angelsächsischen Sprachgebrauch findet sich im Zusammenhang mit Group- 
ware auch der Begriff Computer Supported Cooperative Work. Vgl. zu Groupware 
z.B. Goleman und Khanna (1995). 
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• Vertraulichkeit: Bekanntgabe der betroffenen Daten nur an Berechtigte, 
z.B. durch Verschlüsselung von Nachrichten 

• Datenintegrität: Unveränderlichkeit der Daten, d.h. auch Sicherstellung 
der unmodifizierten Übertragung von Nachrichten (Vollständigkeit und 
Richtigkeit) 

• Zurechenbarkeit: Identifizierung der Instanz, die für ein bestimmtes Er- 
eignis (z.B. Datenzugriff) verantwortlich ist, d.h. Authentifikation (ein- 
deutige Identifizierung von Kommunikationsteilnehmern) und digitale Un- 
terschriften (eindeutige Identifizierung von Nachrichtenerstellern) 

• Verfügbarkeit: ständige Verfügbarkeit und korrekte Funktionalität der 
angebotenen Dienste 

• Kontrollierter Zugang: Zugriff auf Daten und Dienste nur für Berech- 
tigte, z.B. durch Authentifikation 

In der Regel kann nicht davon ausgegangen werden, dass die Hardware bzw. 
die Kommunikationsinfrastruktur per se entsprechende Sicherheiten bietet, so 
dass man im Allgemeinen von einer „Unsicherheit“ genutzter Rechnernetze 
ausgeht und die notwendige Funktionalität somit auf einer Ende-zu-Ende- 
Basis sicherstellen muss. Daraus ergibt sich die Notwendigkeit zum Einsatz 
von entsprechenden Sicherheitsmechanismen. 

In den folgenden Abschnitten wird daher auf mögliche Bedrohungen der 
Sicherheit von Rechnern, Netzen und Anwendungssystemen sowie entspre- 
chende Sicherheitsmechanismen eingegangen. ^ Der Kryptographie kommt da- 
bei eine besondere Bedeutung zu, weshalb sie in Abschnitt 7.2.3 gesondert 
ausführlicher dargestellt wird. 

7.2.1 Bedrohungen der Sicherheit 

Ausgehend von den oben angegebenen Anforderungen an die Sicherheit von 
Rechnern, Netzwerken und Anwendungssystemen können diverse technische 
Bedrohungen unterschieden werden (vgl. u. a. Schäfer (2003)): 

• Maskerade (Vorgaukeln der Identität eines anderen) 

• Abhören (Lesen von Daten, die für jemand anderen bestimmt sind) 

• Autorisierungsverletzung (Unberechtigte Nutzung von Diensten und Res- 
sourcen) 

• Verlust oder Modifikation von Daten 

• Fälschung von Daten (Änderung oder Erzeugung von Daten unter Nutzung 
einer fremden Identität) 

• Abstreiten von Ereignissen 

• Sabotage (mit dem Ziel, die Verfügbarkeit oder korrekte Funktion eines 
Dienstes zu verringern) 

^ Eine umfangreiche Übersicht zu verschiedensten (nicht nur technischen) Bedro- 
hungen und Schutzmechanismen für Rechner und Netzwerke geben u. a. Ches- 
wick et al. (2004). 
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Die Realisierung dieser Bedrohungen kann auf vielfältige Art geschehen, 
beispielsweise durch: 

• Nutzung vorhandener „Sicherheitslöcher“ der Systeme, z.B. unver- 
schlüsselte Datenübertragung oder fehlender Passwortschutz 

• Ausspähen von Passwörtern und ähnlichen Identifizierungsmerkmalen auf 
verschiedenste Weise 

• Viren und Würmer, d. h. Programme, die sich selbstständig vervielfältigen 
können und Schäden anrichten, beispielsweise durch Ausspionieren von Da- 
ten (z. B. Passwörtern) oder auch Veränderung von Programmcode, so dass 
Anwendungssysteme nicht mehr korrekt funktionieren 

• „Spam“-Mails, die zum einen oftmals Viren oder Würmer beinhalten, zum 
anderen durch Überlastung von Mail-Systemen Schaden anrichten können 

• „Denial of Service“-Attacken (DoS), bei denen ein Dienst bzw. ein Rech- 
ner absichtlich so oft aufgerufen wird, dass das zugrundeliegende System 
überlastet wird und damit die Verfügbarkeit eingeschränkt wird® 

Eine Gefährdung für die Sicherheit kann nicht nur von technischen Sys- 
temen, sondern auch von (menschlichen) Nutzern oder den für die Sicherheit 
der Systeme Verantwortlichen ausgehen. Ersteres geschieht häufig im Umgang 
mit Passwörtern, beispielsweise durch die Verwendung von leicht zu erraten- 
den Passwörtern oder auch die Ablage von Passwörtern an ungeschützten 
Stellen. Für Letzteres lieferte die TU Braunschweig ein prominentes Beispiel, 
wo die Spam- und Virenanalyse für eingehende E-Mails abgeschaltet wurde, 
da der Zeitaufwand für diese Analyse alle Ressourcen ausschöpfte; vgl. König 
(2004). Daraufhin wurden mit Hilfe der nun ungeschützten E-Mail-Zugänge 
Rechner der TU als Ausgangspunkt für Spam- und Virenangriffe genutzt. 

Technische Sicherheitsmechanismen können daher nicht alle Bedrohungen 
abwenden, sie bilden jedoch ein grundlegendes Instrumentarium zur Abwehr 
von Sicherheitsgefahren. Einige dieser Mechanismen werden im folgenden Ab- 
schnitt vorgestellt. 

7.2.2 Sicherheitsmechanismen 

Technische Sicherheitsmechanismen dienen dazu, Bedrohungen für die Si- 
cherheit von Rechnern, Netzwerken und Anwendungssystemen abzuwehren 
bzw. zusätzliche Hindernisse für potenzielle Gegner zu bilden. Eine absolute 
Sicherheit von Systemen lässt sich jedoch auch damit nicht erzielen, wenn 
gleichzeitig die Systeme für berechtigte Nutzer verfügbar sein sollen. Es geht 
vielmehr darum, die Realisierung einer Gefährdung von Daten, Netzen oder 
Systemen zu erschweren, gegebenenfalls auch dadurch, dass der Aufwand für 
einen potenziellen Gegner seinen Nutzen übersteigt, so dass die Schädigung 
unwirtschaftlich wird. 

® Oftmals werden für diese künstlich erzeugten Aufrufe fremde Rechner genutzt, 
die zuvor mit Hilfe von Viren, Würmern oder ähnlichen Schädlingen infiziert 
wurden. 
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Weit verbreitete Sicherheitsmechanismen sind unterschiedliche Filtertech- 
niken, wie Virenschutzprogramme, Spamfilter und Firewalls. Firewalls dienen 
u. a. dazu, gezielt bestimmte Port-Nummern (vgl. Abschnitt 2.5.3, S. 48) zu 
sperren, so dass die damit verbundenen Dienste nicht über das Netzwerk 
verfügbar sind. Ebenso kann hiermit die Kommunikation zu einem externen 
Rechner detailliert administriert werden, indem nur bestimmte interne Pro- 
gramme Zugriff auf das Rechnernetz erhalten. Mit derartigen Filtermecha- 
nismen kann das Eindringen schädlicher Software in die hinter der Firewall 
liegenden Rechner verhindert werden, wobei allerdings eine Abwehr unbe- 
kannter Schädlinge nicht vollständig möglich sein wird. Auch DoS-Attacken 
können damit erschwert werden. 

Ein wichtiger Sicherheitsmechanismus gegen das unbefugte Eindringen 
in ein System ist eine sichere Identifizierung. Dies kann über Passwörter, 
aber bei Personen auch über biometrische Merkmale, wie Fingerabdrücke, 
geschehen. In jedem Fall muss sichergestellt werden, dass die Vergleichsdaten 
(z. B. die Merkmale des Fingerabdrucks eines berechtigten Nutzers) so im 
System gespeichert sind, dass kein unberechtigter Zugriff darauf möglich ist. 

Eine sehr große Bedeutung für die Sicherheit von Netzen und Systemen 
besitzen Verschlüsselungstechniken; vgl. Abschnitt 7.2.3. Hiermit kann sowohl 
das Abhören von Nachrichten und das Lesen von Daten durch unberechtigte 
Nutzer verhindert als auch eine eindeutige Authentifizierung von Kommu- 
nikationspartnern und Identifizierung von Nachrichtenerstellern mittels digi- 
taler Signatur ermöglicht werden. Im Folgenden werden daher verschiedene 
kryptographische Verfahren vorgestellt. 

7.2.3 Kryptographie 

Gegenstand der Kryptographie ist die Kommunikation in der Gegenwart von 
Gegnern. Kryptographie als Wissenschaft wird in der Regel als Teilgebiet der 
Mathematik bzw. Informatik angesehen, das sich primär mit Methoden zur 
Verschlüsselung von Nachrichten beschäftigt. Dabei kommen Kryptosysteme 
zum Einsatz; hierunter versteht man Systeme bei Nutzung eines Kommunika- 
tionssystems in der Gegenwart von Gegnern mit dem Zweck der Abwehr von 
dessen Absichten. Bei der Kryptoanalyse besteht die Zielsetzung darin - aus 
der Sicht eines potenziellen Gegners - Kryptosysteme zu brechen. Kryptologie 
kann man als die Zusammenfassung von Kryptographie und Kryptoanalyse 
bezeichnen. 

Im Folgenden seien einige Anwendungsmöglichkeiten von Kryptographie 
genannt: 

• Vertrauliche Abwicklung von Datenübertragungen in einem Rechnernetz, 
z.B. : 

— Übertragung einer vertraulichen Nachricht per E-Mail 

— Vertrauliche Übertragung einer Kreditkartennummer im WWW 

• Schutz der Daten auf einer Festplatte (im Hinblick auf Geheimhaltung) 
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• Überprüfbarkeit des Absenders einer elektronischen Bestellung 

• Nachweisbarkeit einer elektronischen Kommunikation 

• Digitales Geld und digitale Briefmarken 

• Digitale Wahlen 

Bei der Anwendung kryptographischer Verfahren sind neben den anfangs 
genannten funktionalen Anforderungen zwei weitere Aspekte hervorzuheben: 
Zum einen sollten die Verfahren sicher sein, d. h. von einem Gegner in der 
Regel nicht zu brechen sein. Zum anderen sollten die Verfahren einfach an- 
zuwenden sein (im Idealfall transparent für den Nutzer). 

Kryptographische Verfahren werden seit Jahrtausenden im Rahmen der 
Diplomatie bzw. in Kriegen zur Übermittlung geheimer Nachrichten ange- 
wandt; vgl. z. B. Kahn (1972) sowie Singh (2000). Beispiele hierfür sind 
der Einsatz einfacher Buchstaben-Ersetzungsverfahren (wie Verschiebung um 
vier Stellen im Alphabet). Solche Verfahren sind allerdings sehr unsicher; 
beispielsweise ist durch Häufigkeitsuntersuchung einzelner Buchstaben oder 
durch einfaches Durchprobieren eine solchermaßen codierte Nachricht in der 
Regel leicht zu entschlüsseln. Ähnliche Verfahren erweisen sich jedoch sogar 
aus informationstheoretischer Sicht als sicher (d. h. in der codierten Nachricht 
allein sind keinerlei Informationen über die Ursprungsnachricht mehr enthal- 
ten, so dass ein Entschlüsseln der Nachricht für einen Gegner ohne weitere 
(Zusatz-)Informationen unmöglich ist). Hierbei handelt es sich beispielswei- 
se um Verfahren, die Buchstabenersetzungen durchführen, aber dabei für je- 
den Buchstaben eine neue Ersetzungsvorschrift verwenden {One- Time- P ads) . 
Voraussetzung ist das Vorhandensein der Godierungsvorschriften auf beiden 
Seiten der Kommunikation. Hierbei können z. B. Kuriere verwandt werden; 
gelangen die Kuriere unversehrt zum Kommunikationspartner, können die 
entsprechenden Godierungsvorschriften durchgeführt werden. 

Da die aus informationstheoretischer Sicht sicheren Verfahren typischer- 
weise aus verschiedenen Gründen nicht praktikabel sind, sind die Anforde- 
rungen an die Güte kryptographischer Verfahren in Abhängigkeit von der 
Anwendung zu relativieren. Unter einem sicheren Verfahren versteht man des- 
halb in der Praxis zumeist ein solches, bei dem voraussichtlich der Aufwand 
zum Entschlüsseln der codierten Nachricht zu groß ist. Problematisch ist 
allerdings die hierbei notwendige Abschätzung der Ressourcen (wie Zeit, Re- 
chenkapazität), die benötigt werden, um das Verfahren zu brechen. Während 
entsprechende Unwägbarkeiten bei dem (vermeintlich geheimen) Übersenden 
einer privaten Nachricht tolerabel sein können, sind z. B. an Kryptosyste- 
me im Zusammenhang mit der Einführung von Standards für Elektronisches 
Geld höhere Anforderungen zu stellen. 

Im zwanzigsten Jahrhundert ergab sich durch das Entstehen neuer elekt- 
ronischer Übertragungsmöglichkeiten (z. B. drahtlose Kommunikation) ein 
wachsender Bedarf für kryptographische Verfahren (insbesondere auch durch 
den zweiten Weltkrieg). In der zweiten Hälfte des 20. Jahrhunderts entstand 
dann erstmals auch ein weitergehender ziviler Bedarf für den Einsatz kryp- 
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tographischer Verfahren. In den 1970er Jahren wurden symmetrische kryp- 
tographische Verfahren standardisiert. Ebenfalls in den 1970er Jahren ergab 
sich durch die Entwicklung von asymmetrischen Verfahren ein unerwarteter 
Durchbruch, da nunmehr der einer Kommunikation bei symmetrischen Ver- 
fahren notwendigerweise vorausgehende Austausch eines geheimen Schlüssels 
entfallen konnte. 

Im Internet werden heute kryptographische Methoden verbreitet ver- 
wendet. Ein Beispiel ist das ursprünglich von Netscape entwickelte und in- 
zwischen standardisierte SSL-Protokoll {Secure Socket Layer), das Übertra- 
gungsprotokolle wie etwa HTTP um eine Verschlüsselungsfunktionalität er- 
weitert. Nichtsdestotrotz stellt die Gewährleistung einer hinreichenden Si- 
cherheit im Internet noch ein in weiten Bereichen unbefriedigend gelöstes 
Problem dar; vgl. z.B. Fischer et al. (2000) sowie Fuhrberg et al. (2001). 

Im Weiteren werden einige symmetrische und asymmetrische kryptogra- 
phische Verfahren kurz vorgestellt; als umfassende Referenzen hierfür sei auf 
Schneier (1996) sowie Beutelspacher et al. (2004) verwiesen. Es ist allerdings 
zu betonen, dass geeignete kryptographische Verfahren allein nur einen Be- 
standteil der Gestaltung sicherer Systeme darstellen, da im Rahmen kom- 
plexer, realer Systeme Sicherheit nicht nur auf technische Aspekte reduziert 
werden kann; vgl. Schneier (2004). 

7.2. 3.1 Symmetrische Verfahren. 

Symmetrische Verfahren besitzen die primäre Funktionalität der ver- 
schlüsselten Übertragung einer Nachricht M zwischen Kommunikationspart- 
nern, die im Besitz eines gemeinsamen geheimen Schlüssels K sind (deswegen 
der Begriff symmetrisch). Dieser muss zuvor über einen sicheren Kommuni- 
kationskanal übertragen werden. Dies ist allerdings insbesondere bei wechsel- 
seitiger Kommunikation mit vielen Partnern von Nachteil. So sind bei einer 
Kommunikation mittels symmetrischer Verfahren bei n Partnern n(n — l)/2 
Schlüsselpaare notwendig, woraus sich entsprechende Probleme bei Schlüssel- 
verteilung und Verwaltung ergeben (insbesondere auch im Zusammenhang 
mit spontaner Kommunikation). 

Bezeichnet man das Verschlüsselungsverfahren mit E sowie das Ent- 
schlüsselungsverfahren mit D (jeweils unter Verwendung des geheimen 
Schlüssels K), so kann man den grundsätzlichen Verfahrensablauf einer gehei- 
men Übermittlung einer Nachricht M zwischen zwei Kommunikationspart- 
nern wie in Abbildung 7.3 veranschaulicht darstellen. 

Das bekannteste symmetrische kryptographische Verfahren ist die DES- 
Methode (z.B. Data Encryption Standard). Der grundsätzliche Ablauf bei 
der Godierung bzw. Decodierung von Nachrichten sei hier nur kurz ange- 
deutet: Es wird, unter Verwendung eines Schlüssels der Länge 56 Bit, bei 
der Verschlüsselung von jeweils 64-Bit-Datenblöcken eine iterative Kombina- 
tion von einfachen Verschiebe-, Ersetzungs- und logischen XOR-Operationen 
durchgeführt (und umgekehrt bei der Entschlüsselung die gleichen Metho- 
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Abbildung 7.3. Symmetrische Verfahren 



den). Dementsprechend ist das DES- Verfahren einfach und effizient - gege- 
benenfalls auch in Hardware - zu implementieren (mit Verschlüsselungsraten 
von mehr als 100 MBit/s). Die bei der ursprünglichen DES-Methode ver- 
wandte Schlüssellänge von 56 Bit wird inzwischen allgemein anerkannt als 
nicht (mehr) sicher angesehen. Heute kommen bei entsprechenden Anforde- 
rungen deshalb Erweiterungen (z. B. Triple-DES) oder neue Verfahren zum 
Einsatz. 

Ein bekanntes neues symmetrisches Verfahren ist der Advanced Encrypti- 
on Standard (AES), der 2002 offiziell verabschiedet wurde; vgl. u. a. Schäfer 
(2003). Dieses Verfahren unterstützt verschiedene Schlüssellängen von 128 bis 
256 Bit und verwendet standardmäßig eine Blockgröße von 128 Bit, wobei 
auch eine Verschlüsselung mittels größerer Datenblöcke möglich ist. Diese Da- 
tenblöcke werden in 10 bis 14 Runden jeweils durch Ersetzungen, Spaltenver- 
tauschungen, Matrizenmultiplikationen und XOR-Operationen verschlüsselt, 
wofür jeweils noch ein Rundenschlüssel genutzt wird. Auch dieses Verfahren 
ist einfach zu implementieren und gleichzeitig sehr leistungsfähig. 

7. 2. 3. 2 Asymmetrische Verfahren. 

Asymmetrische Verfahren bieten über die geheime Übertragung von Nach- 
richten hinaus weitere Möglichkeiten wie digitale Unterschriften und die Si- 
cherstellung von Datenintegrität. Hierzu werden zwei Schlüssel für die Ver- 
bzw. Entschlüsselung verwendet. Hintergrund hierfür sind so genannte one- 
way functions /, die einfach berechenbar sind, während die inverse Funkti- 
on f~^ nicht bzw. nur mit einem erhöhtem Aufwand berechenbar ist (Beispiel: 
Multiplikation versus Faktorisierung). Als spezielle Version solcher Funktio- 
nen besitzen die so genannten trapdoor functions die zusätzliche Eigenschaft, 
dass eine geheime inverse Funktion f~^ existiert, die effizient berechenbar 
ist, sofern man eine entsprechende Zusatzinformation besitzt. 

Der grundsätzliche Ablauf bei asymmetrischen Verfahren kann wie folgt 
dargestellt werden. Voraussetzung ist zunächst, dass jeder Kommunikations- 
partner ein Schlüsselpaar zur Ver- bzw. Entschlüsselung besitzt: der gehei- 
me/private Schlüssel SK {Secret Key) und der öffentliche Schlüssel PK {Pub- 
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lic Key)] PK wird veröffentlicht. Der Absender verschlüsselt die zu übertra- 
gende Nachricht M mittels des öffentlichen Schlüssels PK des Empfängers 
unter Anwendung eines Verfahrens E; der Empfänger kann diese verschlüssel- 
te Nachricht dann mit seinem privaten Schlüssel SK entschlüsseln; vgl. Ab- 
bildung 7.4. 




Abbildung 7.4. Asymmetrische Verfahren 



Ein Nachteil der asymmetrischen Verfahren ist allerdings die Tatsache, 
dass ihre Anwendung deutlich langsamer als bei symmetrischen Verfahren 
ist. Deshalb modifiziert man ihre Anwendung in der Regel folgendermaßen: 
Bei jeder Kommunikation wird ein (pseudo-) zufälliger Sitzungsschlüssel K ge- 
neriert. Die Nachricht wird mittels eines symmetrischen Verfahrens mit dem 
Schlüssel K verschlüsselt; weiterhin wird K mittels eines asymmetrischen 
Verfahrens mit dem öffentlichen Schlüssel PK des Empfängers verschlüsselt. 
Nunmehr werden die verschlüsselte Nachricht und der verschlüsselte Sitzungs- 
schlüssel an den Empfänger übermittelt, vgl. Abbildung 7.5. 




Abbildung 7.5. Kombination von asymmetrischer und symmetrischer Verschlüsse- 
lung 



Asymmetrische Verfahren bieten weiterhin die Funktionalität einer digi- 
talen Unterschrift, d.h. der Nachprüfbarkeit des Absenders einer Nachricht. 
Die Idee hierbei besteht darin, die Nachricht M mit dem eigenen privaten 
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Schlüssel SK zu verschlüsseln; eine erfolgreiche Entschlüsselung mit dem ent- 
sprechenden öffentlichen Schlüssel PK stellt dann sicher, dass die Nachricht 
von dem angenommenen Absender stammt. Aus Effizienzgründen wird auch 
hier das Verfahren wieder modifiziert: Lediglich eine „Zusammenfassung“ 
{message-digest, fingerprint) H(M) der Nachricht wird verschlüsselt (z.B. 
ein so genannter Hash-Wert der Länge 128 Bit). Der Empfänger entschlüsselt 
die verschlüsselte Zusammenfassung, berechnet selbst H(M) und überprüft 
auf Gleichheit; vgl. Abbildung 7.6. Das Verfahren H sollte der Anforderung 
genügen, dass es praktisch nicht möglich ist, zu einer spezifischen Zusam- 
menfassung eine „passende“ Nachricht zu erzeugen; insbesondere sollten zwei 
nahezu identische Nachrichten verschiedene Zusammenfassungen haben. 




Abbildung 7.6. Digitale Signaturen über asymmetrische Verschlüsselung 



Verschlüsselt man auch die Nachricht (s.o.), so erhält man eine geheime 
und authentifizierte Kommunikation. Bei Verwendung von Zusammenfassun- 
gen ist weiterhin die Integrität (Unverfälschtheit) der übertragenen Nachricht 
sichergestellt, was z. B. auch zur Überprüfung der Integrität von Softwarecode 
verwendet werden kann. 

Die prinzipielle Idee asymmetrischer Verfahren, die Verwendung eines 
Paares aus zwei korrespondierenden Schlüsseln zur Ver- bzw. Entschlüsse- 
lung, wurde Mitte der 1970er Jahre von Difhe und Hellman sowie Merkle 
publiziert; vgl. Difhe und Hellman (1976) sowie Merkle (1978). Als Durch- 
bruch für einen konkreten asymmetrischen Verschlüsselungsalgorithmus ist 
insbesondere das so genannte RSA- Verfahren zu nennen, das 1977 von Ri- 
vest, Shamir und Adleman vorgestellt wurde; vgl. Rivest et al. (1978). Der 
prinzipielle Ablauf des RSA- Verfahrens wird im Folgenden knapp dargestellt. 

Man startet mit zwei sehr großen Primzahlen p und q, die nur anfangs 
nötig sind. Hierbei stellt sich zunächst das Problem, wie p und q zu bestim- 
men sind. Nunmehr wählt man eine Zahl e, die relativ prim zu dem Produkt 
(p — 1)(<7 — 1) sein muss (d. h. e und (p — l){q— 1) dürfen keine gemeinsamen 
Faktoren besitzen). Zusammen bilden dann n = pq und e den öffentlichen 
Schlüssel. Der korrespondierende private Schlüssel (n, d) wird abgeleitet, in- 
dem man d als e~^ (mod (p — l)(q — 1)) bestimmt. Hierbei ist die inverse 
Funktion im Sinne der Modulararithmetik definiert; d. h. d ergibt sich als 
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eine Zahl, so dass {d- e) mod {{p— 1) ■ {q— 1)) gleich 1 ist. Die Sicherheit des 
Verfahrens beruht darauf, dass sich n nicht effizient faktorisieren lässt, d. h. 
p und q lassen sich aus n nicht effizient berechnen, so dass auch d nicht ef- 
fizient berechenbar ist. Diese Anforderung lässt sich komplexitätstheoretisch 
genauer spezifizieren, allerdings ohne dass ihre Gültigkeit nachgewiesen wer- 
den konnte. Zu den Einzelheiten und mathematischen Hintergründen wird 
auf Schneier (1996) verwiesen. 

Die Ver- bzw. Entschlüsselung einer Nachricht M bzw. von Nachrichten- 
teilen m wird folgendermaßen durchgeführt: 

Verschlüsselung E von m : c = mod n 
Entschlüsselung D von c : m = c‘^ mod n 

Der Ablauf wird im Folgenden anhand eines einfachen Beispieles verdeut- 
licht (in der Praxis verwandte Größenordnungen für p und q liegen bei 100- 
200 Dezimalstellen). Zunächst muss das Schlüsselpaar generiert werden: 

p = 47 (zufällig gewählte Primzahl) 

q = 71 (zufällig gewählte Primzahl) 

n = 47 • 71 = 3337 

(p - 1) • (g - 1) = 3220 (= 2 • 2 • 5 • 7 • 23) 
e = 79 (e wird zufällig gewählt als relativ prim zu 3220) 
d = 79-1 mod 3220 = 1019 (da (1019 • 79) mod 3220 = 1) 

^ privater Schlüssel: (3337, 1019), öffentlicher Schlüssel: (3337,79) 

Verschlüsselung : 



M = 688 ^ E{m) = 688^® mod 3337 = 1570 



Entschlüsselung : 

E{m) = 1570 ^ D{E{m)) = 1570^°^® mod 3337 = 688 = m 

Eine Angriffsmöglichkeit zum Brechen des RSA-Kryptosystems ist zu- 
nächst der Zugriff auf p, q und d (wobei p und q nach Generierung der 
Schlüsselpaare gelöscht werden können). Somit muss insbesondere d geheim 
gehalten werden. Die zweite primäre Angriffsmöglichkeit ist der Versuch, n 
zu faktorisieren - beispielsweise über neue algebraische Techniken, deren Vor- 
handensein nicht ausgeschlossen werden kann, oder auch mittels bekannter 
ineffizienter Verfahren. 

Um anzudeuten, wie schwer die zukünftige Sicherheit von Kryptosystemen 
einzuschätzen ist, sei auf einen aktuellen ausgefallenen Forschungsansatz hin- 
gewiesen, der nicht primär im Hinblick auf Kryptographie durchgeführt wird, 
als „Abfallprodukt“ aber effiziente Faktorisierungs verfahren erbrächte und 
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damit entsprechende Kryptosysteme brechen würde. Es gibt eine theoreti- 
sche Konzeption für so genannte Quantencomputer, bei denen Berechnungen 
auf den Prinzipien der Quantenmechanik basierend ablaufen würden. Ers- 
te experimentelle Quantencomputer existieren bereits, für die nahe Zukunft 
ist jedoch der produktive Einsatz derartiger Rechner nicht zu erwarten. In 
diesem Zusammenhang sei aber auch angemerkt, dass es andererseits auch 
Ansätze für Quantenkryptosysteme gibt, bei denen im Zusammenhang mit 
dem Austausch eines geheimen Schlüssels die Tatsache ausgenutzt wird, dass 
die Messung an quantenmechanischen Systemen deren Zustand verändert. 

Ein nicht zu unterschätzendes Problem im Zusammenhang mit der 
Anwendung (auch asymmetrischer) kryptographischer Verfahren ist das 
Schlüsselmanagement. Dabei geht es zunächst um eine sichere Abspeicherung 
von geheimen Schlüsseln. Dies kann beispielsweise durch Passwort geschützt 
auf einer Diskette oder (möglichst lokalen) Festplatte erfolgen. Hierzu können 
beispielsweise auch Chipkarten verwendet werden; es gibt auch so genannte 
Krypto-SmartCards, die die Durchführung der Verschlüsselung bzw. Ent- 
schlüsselung implementieren. Bei Verlust geheimer Schlüssel ergibt sich in der 
Regel die Situation, dass Nachrichten, die unter Verwendung des korrespon- 
dierenden öffentlichen Schlüssels verschlüsselt wurden, nicht mehr decodiert 
werden können. 

Ein weiteres Problemfeld ist die Verteilung von öffentlichen Schlüsseln. 
Hierbei muss sichergestellt werden, dass der erhaltene öffentliche Schlüssel 
von dem angenommenen Kommunikationspartner stammt und nicht 
verfälscht wurde. Praktische Ansätze hierfür sind u. a. „Key-Server“ im 
WWW, Verteilung einer Zusammenfassung des öffentlichen Schlüssels (z.B. 
per Visitenkarte), Registrierung bei einer vertrauenswürdigen Institution und 
Verbreitung durch diese. Die Integrität und Authentizität von öffentlichen 
Schlüsseln kann durch eine digitale Unterschrift einer vertrauenswürdigen 
Institution (Zertifizierungsstelle) garantiert werden; eine solche Institution 
garantiert dann damit, dass der öffentliche Schlüssel wirklich von dem ange- 
gebenen Urheber stammt. 



7.3 Anwendungssysteme in der Industrie 

Branchenspezifisch nimmt der Industriebetrieb innerhalb der Betriebswirt- 
schaftslehre eine außerordentlich exponierte Stellung ein, so dass dieser Be- 
reich auch hinsichtlich der Entwicklung betrieblicher Anwendungssysteme ein 
wesentliches Standbein der Wirtschaftsinformatik seit ihren Anfängen aus- 
macht. Historisch gesehen wurden bereits seit den 1970er und 1980er Jah- 
ren verschiedene technische wie betriebswirtschaftliche Konzepte unter dem 
Schlagwort Computer Integrated Manufacturing integriert. In den 1990er Jah- 
ren wurde dann mit großem Erfolg der Begriff des Suppig Chain Managements 
geprägt, hinter dem sich letztendlich eine weitere Dimension der Integrati- 
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on, nämlich die zwischenbetriebliche Integration insbesondere entlang von 
Wertschöpfungsketten, verbirgt. 

7.3.1 Computer Integrated Manufacturing 

Die Bandbreite von Anwendungsmöglichkeiten für betriebliche Anwendungs- 
systeme in der Industrie findet sich insbesondere im Konzept des Compu- 
ter Integrated Manufacturing (CIM) bzw. der computerintegrierten Ferti- 
gung. Der Grundgedanke des CIM-Konzeptes besteht darin, sämtliche tech- 
nischen und betriebswirtschaftlichen Aufgabenbereiche eines Industriebetrie- 
bes mit Hilfe unternehmensweiter Anwendungssysteme, die auf gemeinsamen 
(einheitlichen) Datenbeständen arbeiten, zu unterstützen. Auf betriebswirt- 
schaftlicher Seite wird dabei im Sinne einer klassischen Auftragsabwicklung 
im Wesentlichen die Produktionsplanung und -Steuerung betrachtet, während 
auf technischer Seite Systeme der produktbezogenen Planung und Realisie- 
rung vorherrschen. Im Folgenden beschreiben wir zunächst die gängige funk- 
tionale Ausgestaltung der betriebswirtschaftlichen und daran anschließend 
der technischen Seite. Entsprechende Anwendungssysteme sind z.B. aus Ab- 
bildung 7.7 ersichtlich. 
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Abbildung 7.7. CIM-Konzept; in Anlehnung an Scheer (1997) 



Die im Rahmen der Produktionsplanung und -Steuerung (PPS) anfallen- 
den vielfältigen und komplexen Planungsaufgaben bedingen in hohem Maße 
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den Einsatz entsprechender Anwendungssysteme. Ausgehend von klassischen 
Konzepten sind PPS-Systeme rechnergestützte Systeme, die zur Planung, 
Steuerung und Kontrolle des Materialflusses in sämtlichen die Produktion 
im weiteren Sinne betreffenden Bereichen von der Auftragsbearbeitung über 
die Materialwirtschaft und die eigentliche Produktion bis hin zum Versand 
(logistische Kette) eingesetzt werden.® 

Die Produktionsplanung umfasst eine Vielzahl von Teilproblemen aus den 
Planungsbereichen Produktionsprogramm, Bereitstellung und Produktions- 
prozess mit vielfältigen gegenseitigen Abhängigkeiten. Dies führt dazu, dass 
es zumeist nicht möglich ist, sämtliche Teilprobleme gemeinsam im Rahmen 
einer Simultanplanung zu betrachten, da entsprechende Modelle sehr komplex 
werden und mit heutigen Verfahren nach wie vor nicht immer mit vertretba- 
rem Rechenaufwand optimal gelöst werden können. Darüber hinaus bestehen 
oftmals Schwierigkeiten, die für das Gesamtproblem benötigten Daten in aus- 
reichendem Detaillierungsgrad zu beschaffen und Entscheidungen innerhalb 
der Produktionsplanung auf die verschiedenen Managementebenen im Unter- 
nehmen zu verteilen. 

Daher wird die Produktionsplanung in heutigen PPS-Systemen in der 
Regel als Sukzessivplanung durchgeführt. Dies bedeutet, dass man eine Auf- 
teilung der Produktionsplanung in verschiedene Planungsebenen zu Grunde 
legt, diese Ebenen sukzessive betrachtet und dort entstehende Optimierungs- 
probleme in der Regel heuristisch löst. Dabei werden die Ergebnisse vor- 
hergehender Planungsstufen jeweils als Daten für die nachfolgenden Stufen 
berücksichtigt. Nimmt man eine hierarchische Aufteilung in Planungsebe- 
nen vor, so spricht man von hierarchischer Planung. Um auch Auswirkungen 
von Entscheidungen auf diejenigen in vorhergehenden Planungsebenen mit 
zu berücksichtigen, erfolgt eine Sukzessivplanung in der Regel rollierend. 

Die meisten heutigen PPS-Systeme basieren auf der „Philosophie“ MRP 
II (Manufacturing Resource Planning) mit folgender Grobaufteilung in Pla- 
nungsebenen: Planung des aktuellen Produktionsprogramms (Master Pro- 
duction Schedule), Materialbedarfsplanung, Durchlaufterminierung sowie 
Steuerung und Kontrolle der Produktion.^® 

Bei der Planung des aktuellen Produktionsprogramms werden Primärbe- 
darfe (d. h. unmittelbar Kundenaufträgen oder erwarteten Nachfragen zuor- 
denbare Bedarfe) für Endprodukte und absatzfähige Ersatzteile bestimmt. 
Dazu werden die Daten konkreter Kundenaufträge und Prognosen über Ab- 
satzwerte herangezogen. Dieser Planungsbereich ist in vielen PPS-Systemen 
nur ungenügend unterstützt, obwohl er die Grundlage für die nachfolgende 
Ebene der Materialbedarfsplanung darstellt. 

® Vgl. zur folgenden Darstellung insbesondere Domschke et al. (1997) sowie zu 
intelligenten Konzepten der PPS Drexl et al. (1994). 

Das MRP II-Konzept stellt eine Weiterentwicklung des mrp (Material Require- 
ments Planning) dar. Zu Modellierungsaspekten auch mit Blick auf das Supply 
Chain Management vgl. Voß und Woodruff (2003). Vgl. zu einer umfassenden 
Übersicht der in der Praxis existierenden PPS-Systeme Pandel et al. (1997). 
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Ausgehend von den zuvor ermittelten Primärbedarfen erfolgt bei der 
Materialbedarfsplanung die Bestimmung von Sekundärbedarfen (abgeleite- 
ten Bedarfen) für Zwischen- und Vorprodukte. Dies geschieht mit Hilfe von 
Verfahren zur Stücklistenauflösung unter Berücksichtigung der Periodenzu- 
ordnung der Bedarfe. Dabei wird die Produktstruktur stufenweise, von den 
Endprodukten ausgehend, betrachtet. Für jedes Produkt werden zunächst 
aus den Bedarfen übergeordneter Produkte Bruttobedarfe ermittelt. Daraus 
ergeben sich unter Berücksichtigung der aktuellen Lagerbestände Nettobe- 
darfe, die zu Bestellmengen (bei fremdbezogenen Gütern) bzw. Produktions- 
losen (bei eigengefertigten Produkten) zusammenzufassen sind. Dazu werden 
in den meisten PPS-Systemen auch bei mehrstufiger Mehrproduktfertigung 
häufig nur einfache (Einprodukt-)Modelle verwendet und heuristisch gelöst. 

Ausgehend von den grob terminierten Nettobedarfen erfolgt bei der 
Durchlaufterminierung die zeitliche Einplanung der Produktionsaufträge (Lo- 
se) auf den Produktiveinheiten. Dazu werden Starttermine für die einzelnen 
Arbeitsgänge eines Auftrages bestimmt. 

Bei der Kapazitätsterminierung wird in jeder Periode ein Vergleich zwi- 
schen geplantem Kapazitätsbedarf und verfügbarer Kapazität durchgeführt. 
Reicht in einer oder mehreren Perioden die Kapazität nicht aus, so wird 
im Rahmen eines Kapazitätsabgleichs eine zeitliche Umverteilung von Auf- 
trägen vorgenommen. Dies geschieht häufig mit Hilfe einfacher Heuristiken 
(z. B. Prioritätsregelverfahren), wodurch die wegen zeitlicher Interdependen- 
zen zwischen Produkten und/oder Arbeitsgängen entstehenden Auswirkun- 
gen auf vor- bzw. nachgelagerte Dispositionsstufen jedoch nur ungenügend 
berücksichtigt werden können. 

Nach der Freigabe der Fertigungsaufträge erfolgt im Rahmen der Pro- 
duktionssteuerung die Bildung von Auftragsreihenfolgen für die Produk- 
tiveinheiten (Reihenfolgeplanung) und ihre detaillierte zeitliche Einplanung 
(Feinterminierung). Vor der Auftragsfreigabe und/oder vor der tatsächlichen 
Ausführung eines Auftrages wird im Rahmen einer Verfügbarkeitsprüfung 
festgestellt, ob die erforderlichen Produktionsfaktoren zum geplanten Zeit- 
punkt vorhanden sind. Während der Ausführung erfolgt eine ständige Kon- 
trolle des Auftragsfortschrittes, indem Ist-Daten mit den geplanten Daten 
verglichen werden. Die Erhebung der Fertigungs-Ist-Daten erfolgt über die 
Betriebsdatenerfassung (BDE). Bei Soll-Ist- Abweichungen sind Fertigungs- 
auftragsdaten wie Termine oder Mengen zu revidieren. 

Zur Realisierung all dieser Planungsaufgaben wird eine Fülle von Daten 
benötigt. Diese Grunddaten lassen sich wie folgt unterteilen: 

• Auftragsdaten: Prognosen der Absatzabwicklung und Daten von Kunden- 
aufträgen 

• Teilestammdaten: produktbezogene Informationen bezüglich Teilenum- 
mern, Produktionszeiten, Stückkosten etc. 

Man spricht in diesem Zusammenhang auch von Capacity Requirements Flan- 
ning; vgl. z. B. Shapiro (1999). 
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• Erzeugnisstrukturdaten: Informationen über die Produktstruktur 

• Arbeitsgangdaten: Arbeitspläne mit den zur Erstellung eines Produktes er- 
forderlichen Arbeitsgängen, deren Zuordnung zu Betriebsmitteln und An- 
gaben über Rüst- und Bearbeitungszeiten 

• Betriebsmitteldaten: Informationen über Kapazitäten von Betriebsmitteln 

PPS-Systeme haben sich in der betrieblichen Praxis weitgehend durchge- 
setzt, obwohl die in einigen der Planungsebenen implementierten Lösungs- 
verfahren wenig leistungsfähig sind. Ein Hauptmangel vieler PPS-Systeme 
besteht in der strikt sukzessiven Planung. Durch die relativ späte Beachtung 
von Kapazitäten erhält man oft erhöhte Durchlaufzeiten und damit erhöhte 
Lagerbestände innerhalb der Produktion. Dies kann dazu führen, dass wichti- 
ge Aufträge als Eilaufträge mit erhöhter Priorität (manuell) eingelastet wer- 
den müssen, was zu einer weiteren Erhöhung von Durchlaufzeiten anderer 
Aufträge führen kann. 

Statt einer automatisierten Steuerung der Arbeitsplätze werden oftmals 
Leitstände genutzt, deren Kern ein Anwendungssystem ist, das z.B. die Ist- 
Situation zeigt, Vorschläge macht, Alternativen aufzeigt und z. T. auch eine 
Simulation anbietet. Die Entscheidung über die tatsächliche Steuerung wird 
jedoch vom Menschen getroffen. 

Zum Abschluss der Produktion ist auf Auftragsseite die Produktfort- 
schrittskontrolle durchzuführen, bei der das Anwendungssystem die Betriebs- 
datenerfassung nutzen kann, um den Fertigungsfortschritt zu erkennen. Uber 
die gesamte Produktion hinweg können gegebenenfalls relevante Daten an 
das Rechnungswesen übermittelt werden. 

Zusätzlich zur Produktion können in Industriebetrieben noch weitere, 
betriebswirtschaftliche Bereiche durch Anwendungssysteme unterstützt wer- 
den. Das Marketing und der Verkauf können insbesondere hinsichtlich der 
Kundenanfrage- und Angebotsbearbeitung, der Angebotsüberwachung (d. h. 
automatische periodische Auswertung der Angebote) sowie der Auftragser- 
fassung und -prüfung unterstützt werden. In der Beschaffung bezieht sich 
die Unterstützung durch Anwendungssysteme auf die Bestelldisposition (d. h. 
Bedarfsermittlung für jedes Teil) , die Lieferüberwachung und die Warenein- 
gangsprüfung. Bei der Lagerhaltung werden Anwendungssysteme z. B. für 
die Materialbewertung, die Lagerbestandsführung, die Inventur und die Un- 
terstützung der Abläufe im Lager (Prozesssteuerung) eingesetzt. Beim Ver- 
sand bieten sich die Zuteilung der Produkte auf Aufträge, die Lieferfreiga- 
be und Entscheidung über Teillieferungen, die Fakturierung (d. h. Erstellung 
der Kundenrechnungen) und die Versandlogistik (d. h. möglichst optimale 
Lösung von Dispositionsproblemen) für den Einsatz von Anwendungssyste- 
men an. Für die Lösung der Dispositionsprobleme können dabei Verfahren 
des Operations Research Anwendung finden, um eine geeignete Planungs- 
funktionalität zu erreichen. Auch beim Kundendienst ist die Nutzung von 
Anwendungssystemen möglich. So können eine automatisierte Fehlerdiagno- 
se oder Terminüberwachung die Wartung und Reparatur unterstützen; aber 
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auch die Bearbeitung von Reklamationen kann mit Hilfe von Anwendungs- 
systemen erfolgen. 

Der Produktentwurf bzw. die Konstruktion von Produkten können mittels 
des Computer Aided Engineering (CAE) bzw. des Computer Aided Design 
(CAD) durchgeführt werden. Hierfür besteht die Tendenz, beide Systeme zu 
so genannten Konstruktions-Informationssystemen zu erweitern. Nach der 
Konstruktion eines Produktes ist die Erstellung von Arbeitsplänen (Ferti- 
gungsvorschriften) erforderlich, die mit Computer Aided Planning (CAP) 
teilautomatisiert werden kann. 

Bei der computergestützten Produktion (Computer Aided Manufactu- 
ring: CAM) kann eine Unterstützung von Produktion, Transportieren, La- 
gern, Prüfen und Verpacken durch Anwendungssysteme erfolgen. Insbeson- 
dere die Verwaltung von numerisch gesteuerten Maschinen und von Lagern 
sowie die Steuerung von Fertigungszellen, Flexiblen Fertigungssystemen, Pro- 
zessen u. A. gehören zu den Aufgaben von Anwendungssystemen. Die großen 
Datenmengen (der Betriebsdatenerfassung wie z. B. Maschinen- oder Pro- 
zessdaten) müssen hierbei auf Korrektheit und Plausibilität geprüft werden. 
Im Bereich der Qualitätssicherung kommen Systeme der Computer Aided 
Quality Assurance (CAQ) zum Einsatz, die individuelle Prüfungen veran- 
lassen und Stichproben festlegen. Von großer Wichtigkeit ist ein Frühwarn- 
system, das z.B. im Falle des Auftretens von Störungen im Betriebsablauf 
entsprechende Meldungen ausgibt. 

Abschließend sei noch einmal auf neuere Ansätze zu PPS-Systemen einge- 
gangen. Eine grundlegende Schwäche der meisten in der Praxis eingesetzten 
Systeme besteht darin, Produktionspläne in Unkenntnis der für die Produk- 
tion benötigten Ressourcen zu erstellen. Abbildung 7.8 symbolisiert ein ka- 
pazitätsorientiertes PPS-System, bei dem auf zentraler Planungsebene fest- 
gelegt wird, welche konkreten Endproduktmengen in den einzelnen Perioden 
eines bevorstehenden Planungszeitraumes zu produzieren sind. Übergeordnet 
findet eine aggregierte Gesamtplanung in Form einer Beschäftigungsglättung 
statt, d. h. im Zuge dieser Gesamtplanung ist eine Anpassung der Produk- 
tiveinheiten bzw. Kapazitäten vorzunehmen. 

Auf dezentraler Planungsebene erfolgen die detaillierte Losgrößen- und 
die Ressourceneinsatzplanung sowie eine segmentspezifische Feinplanung. Die 
dabei zu betrachtenden Produktionssegemente weisen spezifische Eigenarten 
auf, die mit geeigneten Methoden des Operations Research zu bearbeiten 
sind. Als Organisationsformen der Fertigung treten z.B. die Werkstattferti- 
gung oder das Just-in-Time-Prinzip (JIT) auf. 

7.3.2 Supply Chain Management 

Logistik umfasst die Gesamtheit aller Aktivitäten, die auf eine bedarfsge- 
rechte Verfügbarkeit von Gütern und Subjekten und somit insbesondere de- 
ren raum-zeitliche Transformation ausgerichtet ist. Die mit dieser (mehrstu- 
figen) Transformation einhergehende Verknüpfung elementarer logistischer 
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Abbildung 7.8. Grundstruktur eines kapazitätsorientierten PPS-Systems; Quelle: 
Drexl et al. (1994), S. 1030 



Leistungsprozesse wird als logistische Kette bezeichnet. Mithin beschreibt der 
Term logistische Kette das Beziehungsgeflecht Beschaffung - Transport - Pro- 
duktion - Distribution, Allokation und Transport - Absatz, d. h. die Funkti- 
onsbereiche der betriebswirtschaftlichen Wertschöpfungskette. Hier setzt das 
Supply Chain Management als prozessorientierte Entwicklung, Gestaltung, 
Koordination und Steuerung aller Aktivitäten entlang der logistischen Kette 
an.^^ 

Im Gegensatz zur Logistik reicht das Supply Ghain Management wei- 
ter, indem neben Materialflüssen insbesondere Informations- und Finanz- 
flüsse innerhalb logistischer Ketten bzw. entsprechender Netzwerke betrach- 
tet werden. Anwendungssysteme des Supply Ghain Management lassen sich 
als Ergänzungen zu bestehenden ERP-Systemen auffassen, d. h. sie setzen auf 

Vgl. z.B. Knolmayer et al. (2000), Stadtier und Kilger (2005) sowie Voß und 
Woodruff (2003). 
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der unternehmensweiten Datenverfügbarkeit derartiger Systeme auf und in- 
tegrieren sie im Zuge geeigneter Planungsfunktionalität über Unternehmens- 
grenzen hinweg. Letztendliche Auswirkung kann eine intelligente Synchroni- 
sation der Geschäftsprozesse mehrerer in einem Netzwerk operierender Un- 
ternehmen sein. 

Eine vornehmliche Triebfeder des Supply Chain Managements besteht in 
der verfügbaren IT-Infrastruktur, die einen effizienten Daten- und Informati- 
onsaustausch ermöglicht. Damit einhergehend besteht der Wunsch, über ge- 
eignete Anwendungssysteme eine unternehmensübergreifende Planungsfunk- 
tionalität gewährleistet zu bekommen. Als am weitesten reichender Ansatz 
in diese Richtung sind so genannte Advanced Flanning Systems (APS) ver- 
schiedener Hersteller wie z.B. i2 oder SAP zu nennen, deren Grundstruktur 
in Abbildung 7.9 wiedergegeben ist. 




Abbildung 7.9. Grundstruktur eines Advanced Planning Systems; Quelle: 
Günther und Tempelmeier (2000), S. 339 



Wesentliche Aspekte eines APS sind auf der einen Seite eine weit reichen- 
de Transaktionsdatenverfügbarkeit über ein ERP-System und auf der ande- 
ren Seite geeignete Algorithmen bzw. Lösungsverfahren zur Bestimmung von 
Lösungen für folgende Bereiche: 

• Demand Planning: Prognoseverfahren zur Bestimmung von Nachfragewer- 
ten 
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• Supply Network Flanning: Methoden zur Hauptproduktionsprogrammpla- 
nung unter Berücksichtigung von Beschaffungs-, Produktions- und Trans- 
portmengen 

• Production Flanning: Methoden der Produktionsplanung sowie der Res- 
sourceneinsatzplanung 

Durch den Daten- und Informationsaustausch sollen in APS darüber hin- 
aus zwei weitere Konzepte berücksichtigt werden: Vendor Managed Inven- 
tory sowie Availahle/Capable to Promise. Unter Vendor Managed Invento- 
ry wird die Steuerung von Lagerbeständen eines Unternehmens durch seine 
Lieferanten verstanden. Available to Promise demgegenüber bedeutet eine 
(gegebenenfalls in Echtzeit durchführbare) Verfügbarkeitsprüfung, mit der 
Kundenanfragen bzw. Nachfragen verlässlich beantwortet werden können. 

Ein Anwendungssystem, welches Eingang in APS findet bzw. finden kann 
und welches sich konsequent mathematischer Methoden bedient, ist die ILOG 
Optimization Suite des Unternehmens ILOG (http://www.ilog.com). Aus- 
gangspunkt sind geeignete Werkzeuge zur Lösung kombinatorischer, gemischt 
ganzzahliger sowie linearer Optimierungsprobleme. Die ILOG Optimization 
Suite besteht aus einer Vielzahl an Komponenten, die z.T. mittlerweile auch 
in betriebswirtschaftliche Standardsoftware eingebunden sind bzw. eingebun- 
den werden können (als Beispiel seien Anwendungssysteme genannt, die in 
Ergänzung zu ERP-Systemen wie SAP R/3 bzw. mySAP versuchen, geeig- 
nete Planungsfunktionalität zu ergänzen). 

Innerhalb der ILOG Optimization Suite finden sich Werkzeuge, die z. B. 
die mathematische Modellierung von Problemen unterstützen.^^ Im Bereich 
der Kapazitätsplanung sind spezielle Module vorhanden, die Ressourcenbe- 
schränkungen berücksichtigen. Unter dem Begriff Goncurrent Scheduling wer- 
den Methoden zur Lösung von Problemen der Verfügbarkeitsprüfung (Availa- 
ble to Promise bzw. Gapable to Promise) vorgehalten. Als Beispiel erläutern 
wir den ILOG Dispatcher etwas näher. 

Das Modul ILOG Dispatcher dient der Tourenplanung sowie der Perso- 
naleinsatzplanung. Basierend auf vordefinierten Objekten lassen sich Touren- 
planungsprobleme sowie ihre Gharakteristika wie Kapazitäten, Kundenzeit- 
fenster oder Arbeitszeitbeschränkungen (z. B. Lenkzeitbeschränkungen einzu- 
setzender Fahrer) modellieren. Die grundsätzliche Vorgehensweise zur Lösung 
derartiger Probleme bedient sich moderner heuristischer Prinzipien wie dem 
Tabu Search; vgl. Abschnitt 2.1.3. Weitere Optionen, die im Zuge des Supply 
Ghain Managements Berücksichtigung finden können, sind mehrere Stand- 
orte (Multidepot Vehicle Routing) oder Planänderungen in Echtzeit. 

„Mathematical programming models are critical elements of analytical IT. [...] 
They are the only analytical tools capable of fully evaluating large numerical 
data bases to identify optimal, or demonstrably good, plans.“ (Shapiro (1999), 
S. 740) 
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7.4 Anwendungssysteme im Dienstleistungsbereich 

Dienstleistungsunternehmen sind insbesondere dadurch gekennzeichnet, dass 
ihre Produkte im Kern immaterielle Wirtschaftsgüter sind. Beispiele sind Un- 
ternehmen aus den Bereichen Transport und Verkehr sowie Banken und Fi- 
nanzdienstleistungen. Ausgehend von den vier Phasen einer Dienstleistungs- 
produktion 

• Realisierung der Leistungsbereitschaft durch Kombination interner Pro- 
duktionsfaktoren (z.B. Bereitstellung von Transportmitteln), 

• Leistungsvereinbarung mit dem Kunden (z.B. Erwerb eines Fahrscheins), 

• Leistungserbringung bzw. -durchführung (z. B. Transport einer Person oder 
eines Gutes) und 

• Nachbehandlung (z.B. Inkasso nach dem Erwischtwerden beim Schwarz- 
fahren, d.h. der unberechtigten Inanspruchnahme einer Dienstleistung) 

lassen sich eine Vielzahl an Anwendungssystemen im Dienstleistungsbereich 
beschreiben. Wesentliche Aspekte bestehen letztendlich in der effizienten 
Steuerung von Informationsflüssen (Informationslogistik).^^ 

Unterstützungssysteme im Dienstleistungsbereich lassen sich z. B. im 
Gesundheitswesen, bei Banken, im Bibliothekswesen oder im Hotel- und 
Gaststättengewerbe finden. Exemplarisch geben wir im Folgenden einige Hin- 
weise zu einfachen Auskunfts- und Beratungssystemen, zum Gustomer Rela- 
tionship Management sowie für das Revenue Management. 

7.4.1 Auskunfts- und Beratungssysteme 

Im unmittelbaren wie im mittelbaren Kundenkontakt können Auskunfts- und 
Beratungssysteme die Leistungsvereinbarung mit dem Kunden unterstützen. 
Beispiele sind hier Fahrgastinformationssysteme^® im Bereich des Verkehrs, 
Auskunfts- und Buchungssysteme in einem Reisebüro oder Vertriebssysteme 
für Außendienstmitarbeiter in verschiedenen Branchen wie z.B. der Versiche- 
rungswirtschaft. Bezieht man derartige Systeme etwa auf den Wertpapier- 
handel, so ist es offensichtlich, dass dies unmittelbar auch den Bereich des 
Electronic Gommerce mit entsprechenden elektronischen Märkten betrifft; 
vgl. hierzu Abschnitt 7.6. 

Weiterführend sei in diesem Abschnitt kurz eine Anbindung an den Be- 
reich der Anwendungssysteme in der Verwaltung diskutiert.^® Im Zuge der 
Bereitstellung von Informationsangeboten eröffnen sich Optionen für eine 

Vgl. z.B. Voß und Domschke (1999) sowie Voß und Gutenschwager (2001). Zu 
einer Einführung in die Wirtschaftsinformatik im Dienstleistungsbereich sei Bo- 
dendorf (1999) genannt. 

Vgl. z.B. Daduna und Voß (1994) oder Schneidereit et al. (1998) sowie Ab- 
schnitt 7.5. 

Wir sind uns sehr wohl der Tatsache bewusst, dass sich der Verwaltungsbe- 
reich möglicherweise sowohl in der Praxis wie auch in der Theorie ungern dem 
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funktionale Vernetzung verschiedener Informationsbereiche, wie man sie z. B. 
in so genannten Stadtinformationssystemen finden kann. Derartige Systeme 
verfügen über ein breit gefächertes Informationsangebot, welches sich aus 
den folgenden Bereichen zusammensetzen kann: Fahrgastinformationen, In- 
formationen über (touristische) Sehenswürdigkeiten, Veranstaltungsinforma- 
tionen sowie Verwaltungs- und Dienstleistungsinformationen („Bürgerinfor- 
mationen“). 

Im Bereich multifunktionaler Informationssysteme zählen hierzu insbe- 
sondere multimediale Kiosksysteme, die sich dadurch auszeichnen, dass die 
entsprechenden Benutzerschnittstellen an öffentlich zugänglichen Orten plat- 
ziert sind und von häufig wechselnden, meist anonymen Benutzern frequen- 
tiert werden. Hinsichtlich des Interaktionsgrades mit einem Kiosksystem las- 
sen sich die folgenden drei Stufen unterscheiden: 

• Animationskiosk: Die Art und Reihenfolge sowie der Umfang der vom Sys- 
tem bereitgestellten Informationen ist nicht beeinflussbar. 

• Interaktionskiosk: Die Art, Reihenfolge und der Umfang der vom Benutzer 
abgerufenen Informationen ist durch Interaktion beeinflussbar. 

• Transaktionskiosk: Der Benutzer kann durch Interaktionen mit dem Sys- 
tem entsprechende Transaktionen auslösen und auf diese Weise die im Sys- 
tem gehaltenen Daten „manipulieren“. 

Multimediale Kiosksysteme erlauben die Integration verschiedener Be- 
reiche mit diversen Funktionalitäten, so dass ihr Leistungsspektrum breit 
gefächert ist. Dabei ist es ohne weiteres möglich, die Kernstruktur von Stadt- 
informationssystemen zu realisieren. Als Informations- und Dienstleistungs- 
anbieter sind sowohl „kommerzielle“ (z. B. Hotel- und Gastronomiegewerbe, 
Einzelhandel, Konzertveranstalter etc.) als auch „nicht-kommerzielle“ Anbie- 
ter (Verwaltungen und Betriebe der öffentlichen Hand) zu finden. Während 
Erstere eher eine marketingorientierte Informationsbereitstellung betreiben, 
sind Letztere oftmals eher einer Daseinsfürsorge verpflichtet. 

Mittlerweile hat es sich als Standard erwiesen, dass städtische Kiosksys- 
teme über eine Zahlungs- und Buchungsfunktion verfügen können. Auf diese 
Weise lassen sich zahlreiche der im System angebotenen Leistungen während 
der Recherche buchen bzw. erwerben (z. B. Hotelzimmer, Theaterkarten). 

7.4.2 Customer Relationship Management 

Ausgehend von der Differenzierung zwischen Front Office und Back Office 
(vgl. Abschnitt 7.1.3) lassen sich in allen Phasen des Dienstleistungsberei- 
ches diverse Anwendungssysteme angeben. Dies kann im Front Office z. B. 

Dienstleistungsbereich zuordnen lässt. Ein entsprechender Paradigmenwechsel 
wäre jedoch zu begrüßen. 

Anwendungssysteme im Verwaltungsbereich betreffen so unterschiedliche The- 
men und Bereiche wie das Einwohnermeldewesen, Finanzämter, die Polizei oder 
Liegenschaftsämter . 
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die Ansprache potenzieller Kunden über geeignete Informationssysteme be- 
deuten. Aus Marketingsicht lässt sich dies jedoch nicht auf reines Informie- 
ren beschränken, so dass unter dem Schlagwort Customer Relationship Ma- 
nagement (CRM) oftmals ein ganzheitliches Konzept zur Unterstützung von 
Kundenbeziehungen bzw. einer Vereinfachung der Steuerung der Kundenan- 
sprache unter Einbeziehung entsprechender Anwendungssysteme verstanden 
wird. 

Zum CRM können u. a. Systeme des Back Office mit geeigneter Ana- 
lysefunktionalität (z.B. Methoden des Data Mining) gehören, um Kunden- 
präferenzen erkennen und speziell darauf abgestimmte Systemfunktionalität 
bereithalten zu können. Hinsichtlich der Datenverfügbarkeit ist eine geeignete 
Integration dergestalt zu gewährleisten, dass Kundendaten verschiedener Sys- 
teme mit gegebenenfalls unterschiedlichen Schlüsselattributen für identische 
Kunden zu konsolidieren sind. Dies kann Daten hinsichtlich offener Bestel- 
lungen und offener Zahlungen (bzw. zur Zahlungsmoral) eines Kunden, die in 
einem ERP-System vorliegen, oder Aufzeichnungen eines Call Centers über 
Kundenreaktionen, z.B. bei Beschwerdevorgängen, betreffen. 

Ein CRM-System kann einem Nutzer für Aktionen der Kundenanspra- 
che im Zuge einer zielgerichteten Auswahl in Betracht kommende Kunden 
auf der Basis detaillierter Kundenprofile sowie geeignete Kommunikations- 
kanäle angeben, nach denen eine Filterung verfügbarer Daten (im Sinne einer 
Segmentierung) vorzunehmen ist. Aktivitäten vermöge verschiedener Kanäle 
sind als solches zu dokumentieren, um unerwünschte Mehrfachansprachen 
zu verhindern. Darüber hinaus lassen sich standardisierte Vorgänge wie das 
Veranlassen der Versendung von Glückwunschkarten zu Kundengeburtstagen 
u. A. integrieren. 

7.4.3 Revenue Management 

Unter Revenue oder Yield Management verstehen wir die Kapazitätsplanung 
und Preisgestaltung in der Dienstleistungsproduktion mit dem Ziel der Er- 
tragsmaximierung; vgl. z.B. Klein (2001). Wesentliche Aspekte sind eine 
Kombination proaktiver und analytischer Prozesse, um Nachfrage und Bedarf 
nach einer Dienstleistung mit dem genannten Ziel in Einklang zu bringen. 

Veranschaulichen lässt sich das Revenue Management am Beispiel von 
Unternehmen des Luftverkehrs, die das Revenue Management in Verbindung 
mit geeigneten Reservierungssystemen durchführen. Typische Merkmale der 
Dienstleistung Personenbeförderung sind in diesem Fall die folgenden Krite- 
rien: 

• geringe Flexibilität der Kapazität, da eine Anpassung nur mit hohem fi- 
nanziellen Aufwand sowie in der Regel nicht kurzfristig durchführbar ist 

• hohe Fixkosten („sunk cost“) für die Bereitstellung der Kapazität 

• geringe Grenzkosten der eigentlichen Leistungserstellung (z. B. für Bord- 
service) 
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• Ertragsverlust oder -minderung bei Nichtinanspruchnahme der Kapazität 
(„Verderblichkeit“ der Kapazität) 

• Nachfrageunsicherheit 

• Option der Marktsegmentierung sowie der Preisdifferenzierung 

• Option der Vorausbuchung der Leistung 

Anwendungssysteme im Bereich Revenue Management verfolgen die 
Steuerung der Produktverfügbarkeit auf der Basis unterschiedlicher Prei- 
se verbunden mit unterschiedlichen Zusicherungen hinsichtlich der Möglich- 
keit der Leistungsinanspruchnahme. Zu prognostizieren sind somit für je- 
de Flugverbindung und gegebenenfalls für jeden Abffugtermin Daten und 
Wahrscheinlichkeitsverteilungen verschiedener Buchungsklassen sowie die da- 
mit verbundenen Buchungszeiträume, d. h. eine Prognose der für einen Flug 
im Zeitablauf noch eintreffenden Buchungsanfragen, Stornierungen sowie so 
genannte No-Shows (Passagiere, die ohne Stornierung ihrer Buchung nicht 
zum Flug erscheinen) und Go-Shows (Passagiere mit gültigem Flugschein, 
die nicht im Reservierungssystem erfasst sind). 

Ein wesentlicher Mechanismus, mit dem im Revenue Management gear- 
beitet wird, ist die „Überbuchung“. Statische Modelle zur Überbuchung legen 
ein statisches Buchungslimit für verbleibende Buchungszeiträume fest. Dabei 
werden insbesondere Wahrscheinlichkeitsverteilungen in Abhängigkeit vom 
Buchungslimit ermittelt und berücksichtigt. Als Ersatzziel wird dabei oft- 
mals die Minimierung der Wahrscheinlichkeit zurückgewiesener Reservierun- 
gen unter Einhaltung bestimmter Restriktionen (z. B. Mindestauslastung von 
90%) verfolgt. Die Planung erfolgt in der Regel rollierend. Dies bedeutet, dass 
Pläne während des Planungszeitraumes, d. h. vor Erreichen des Planungsho- 
rizontes, aufgrund veränderter Daten (gegebenenfalls mehrfach) modifiziert 
werden. Dynamische Modelle betrachten darüber hinaus Wahrscheinlichkeits- 
verteilungen für kommende Buchungsanfragen. Ein Anwendungssystem führt 
dies insbesondere in Verbindung mit einem Reservierungssystem durch, an 
welches kontinuierlich Anfragen eingehen, die entsprechend in Echtzeit zu 
beantworten sind; vgl. hierzu das Prinzip des Available to Promise in Ab- 
schnitt 7.3.2. 



7.5 Anwendungssysteme im Verkehrsbereich 

Die Planung und Steuerung von Leistungserstellungsprozessen im Bereich des 
Verkehrs wird (wie in anderen Bereichen auch) in einem erheblichen Umfang 
durch die Qualität und Verfügbarkeit von Daten und Informationen sowie 
den damit einhergehenden IKS beeinflusst. In Abhängigkeit der Art der Ver- 
kehrsabläufe unterscheiden wir vereinfacht folgende drei Bereiche: der (kollek- 
tive) öffentliche Personenverkehr (ÖV), der motorisierte Individualverkehr 
sowie der Güterverkehr . Als weitergehende Differenzierung unterscheidet man 
auch die Bereiche Öffentlicher Personennahverkehr (ÖPNV) (einbezogen ist 
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hierbei auch der Regionalverkehr), Schienenpersonenfernverkehr und Luft- 
verkehr. In diesem Abschnitt geben wir einen Überblick über ausgewählte 
Anwendungssysteme im Verkehrsbereich, die die vorhandene Vielfalt infor- 
mationslogistischer Anwendungen aus dem Bereich des Verkehrs aufzeigen. 

Im Bereich des Verkehrs befinden sich eine Vielzahl von IKS im Einsatz. 
Hierzu gehören übergeordnete Systeme des Verkehrsmanagements (Verkehrs- 
informationssysteme, RDS/TMC: Radio Data System/Traffic Message Chan- 
nel), unternehmensübergreifende Informations- und Kommunikationssysteme 
des Logistikmanagements (u. a. basierend auf Frachtbörsen, Güterverkehrs- 
zentren und Unternehmensnetzwerken), unternehmensinterne Telematiksys- 
teme (Ortungssysteme, Flottenmanagementsysteme), unternehmensinterne 
Tourenplanungssysteme oder Auftragsabwicklungssysteme; z.B. Speditions- 
leitstände, Terminalbetriebsführung). Die genannten Systeme bedienen sich 
diverser Technologien z.B. im Bereich terrestrischer oder Mobilkommunika- 
tion bzw. der Satellitennavigation (z.B. GPS: Global Positioning System). 
Darüber hinaus kommen unterstützend weitere Systeme wie z. B. geographi- 
sche Informationssysteme zum Einsatz. 

7.5.1 Öffentlicher Personenverkehr 

Für den ÖV verknüpfen Anwendungssysteme im Back Office (internes In- 
formationsmanagement) verschiedene Systeme aus dem Bereich der (strate- 
gischen und operativen) Planung der Leistungserstellungsprozesse sowie der 
Betriebssteuerung und Überwachung. Im Front Office (externes Informati- 
onsmanagement) erfolgt die Anbindung an diverse Komponenten der Fahr- 
gastinformation. Beide Bereiche bilden, wie in Abbildung 7.10 skizziert, eine 
integrierte Struktur, die aus den funktionalen Zusammenhängen der einzel- 
nen (Teil-)Aufgabenstellungen resultiert. 

Im Back Office stehen, basierend auf einem relationalen Datenbanksystem 
(DB-System), die IT-gestützte Angebots- und Einsatzplanung sowie ein rech- 
nergestütztes Betriebsleitsystem (RBL) im Vordergrund. Für die Angebots- 
planung ist insbesondere das Datenmanagement der Netz- und Fahrplandaten 
von Bedeutung, welche die Basis für die betriebliche Einsatzplanung bilden. 
Das RBL wird in erster Linie zur Steuerung und Überwachung der Betriebs- 
abläufe eingesetzt, wobei aktuelle Daten auch in zusätzlichen Funktionen 
genutzt werden, wie zum Beispiel einer (dynamischen) Fahrgastinformation. 
Grundlage hierfür sind Ortungs- und Kommunikationssysteme, die bei einer 
entsprechenden technischen Ausstattung eine (weitgehend) lückenlose Erfas- 
sung der Betriebsabläufe ermöglichen. 

Anwendungssysteme im Front Office betreffen insbesondere eine leistungs- 
fähige und kundenorientierte Fahrgastinformation. Intermodale, d. h. sich 

Vgl. zu einer ausführlichen Diskussion sowie als Grundlage der folgenden Dar- 
stellungen insbesondere Daduna und Voß (2000). 
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Abbildung 7.10. Internes und externes Informationsmanagement in Betrieben 
des öffentlichen Personennahverkehrs; Quelle: Daduna und Voß (1995), S. 362 



Über mehrere Verkehrsträger erstreckende, Fahrgastleit- und Informationssys- 
teme beispielsweise integrieren mehrere verkehrsrelevante Auskunftsdienste 
in einer gemeinsamen Plattform. Sie leisten eine effektive Mobilitätsberatung 
und erlauben gegebenenfalls eine Beeinflussung des Verkehrsmittelwahlver- 
haltens der Reisenden. 

Mit dem Ende der 1980er Jahre begann der Einsatz von IT-gestützten 
Auskunftssystemen für die Fahrgastinformation, eine Entwicklung die u. a. 
durch die zunehmende Verfügbarkeit von leistungsfähiger dezentraler Hard- 
ware ermöglicht wurde. Anfangs stand vornehmlich die Fahrplaninformation 
im Vordergrund, wobei die Auskunftserteilung für Einzelfahrten (in Verbin- 
dung mit einem unmittelbaren Fahrtantritt) und die Erstellung relations- 
bezogener persönlicher Fahrpläne die wesentliche Nutzungsform darstellten. 
Ziel hierbei war es, dem Kunden zum einen die Suche nach möglichen Ver- 
bindungen in Verkehrsnetzen zu erleichtern und ihm zum anderen einen be- 
darfsgerechten Auszug aus dem Fahrplanbuch zur Verfügung zu stellen. Er- 
weitert wurde diese Form der Informationsbereitstellung in den folgenden 
Jahren durch die Verknüpfung von Informationen über den Schienenperso- 
nenfernverkehr mit denen des lokalen OPNV sowie durch eine Ausdehnung 
der einbezogenen Gebiete. 

Mit der zunehmenden Verbreitung der Zugangsmöglichkeit zu Netzdiens- 
ten zeigt sich auch im Bereich der Fahrgastinformation eine Entwicklung, 
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die diese Strukturen für eine attraktive Gestaltung der Fahrgastinformati- 
on nutzt. Die Basisfunktion der Fahrplanauskunft kann, mit Blick auf ei- 
ne kundenorientierte Informationsvermittlung, unterschiedliche Funktiona- 
litäten umfassen. 

Aufgrund unterschiedlicher Voraussetzungen bei den (potenziellen) Kun- 
den bietet es sich an, eine benutzerabhängige Wegewahl auf der Basis ver- 
schiedener Kriterien zu erlauben. Diese Wahlmöglichkeit stellt besondere 
Herausforderungen an ein Fahrgastinformationssystem, da je nach Auswahl 
nicht nur die Fahrplanzeiten im Vordergrund stehen (schnellste Verbindung), 
sondern auch Umsteigemöglichkeiten (bequemste Verbindung), behinderten- 
gerechter Ausbau der Verkehrsmittel und Haltestellen (behindertengerechte 
Beförderung) oder die Entfernungen sowie die Zugehörigkeit einer Strecke 
bzw. Haltestelle zu einem Tarifgebiet (geringste Kosten) von Bedeutung sind. 
Somit muss für eine solche Auswahlmöglichkeit entweder die Datenbasis ge- 
zielt um die entsprechenden Informationen erweitert oder auf Seiten der Be- 
rechnungsverfahren eine geeignete Funktionalität vorgehalten werden. 

Neben der Basisfunktion Fahrplanauskunft ist im Zuge einer kundenorien- 
tierten Informationsbereitstellung die Integration weiterer (die Fahrplanda- 
ten ergänzender) Informationen sinnvoll. Neben der statischen Information, 
die auf den gespeicherten Soll-Daten aufbaut, stellt sich auch die Frage ei- 
ner Einbeziehung von aktuellen Betriebsdaten (Ist-Daten). Unabdingbare Vo- 
raussetzung für eine entsprechende Realisierung ist, dass flächendeckend ein 
RBL realisiert ist, mit dessen Hilfe die aktuellen Betriebsdaten erfasst und 
aufbereitet werden. 

Um eine Auskunftserteilung in Abhängigkeit von der jeweiligen Anfra- 
gesituation gewährleisten zu können, sind zwei parallele Datenbestände zu 
führen. Auf der einen Seite sind die Soll-Daten vorzuhalten, mit deren Hilfe 
zum Beispiel die persönlichen Fahrpläne erstellt werden. Auf der anderen Sei- 
te ist ein auf den Soll-Daten basierender Datenbestand erforderlich, der, aus- 
gehend von den im RBL erfassten Abweichungen vom Soll- Ablauf, kontinuier- 
lich korrigiert wird. Berücksichtigt werden können hierbei u. a. Verspätungen, 
Ausfälle einzelner Fahrten oder Fahrten in einem bestimmten Zeitabschnitt 
sowie verkehrstechnisch bedingte Veränderungen im Linienverlauf. Gleichzei- 
tig lassen sich aber auch zusätzliche Fahrten, die zum Beispiel aufgrund von 
kurzfristigen Bedarfsveränderungen erforderlich sind, in die Routenermitt- 
lung einbeziehen. 

Ein weiterer Aspekt in der Diskussion über eine effiziente Gestaltung der 
Fahrgastinformation ist die durchgängige Quelle-Ziel-Auskunft, die sich über 
verschiedene Bedienungsgebiete (und Verkehrsmittel) erstreckt und nur einen 
einzigen Abfragevorgang erforderlich macht (d. h. eine Vernetzung unter- 
schiedlicher Fahrgastinformationssysteme erfordert) . Bei einer durchgängigen 
Routensuche ergibt sich neben dem Problem der dislozierten Datenbestände 
eine zusätzliche Schwierigkeit, die aus der Verknüpfung unterschiedlich kon- 
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zipierter Systeme resultiert, die derzeit in den verschiedenen Bedienungsge- 
bieten im betrieblichen Einsatz sind. 

7.5.2 Güterverkehr 

Unter logistischen Dienstleistern (z. B. Speditionen oder dem Betreiber ei- 
nes Container- bzw. Umschlagterminals) verstehen wir Unternehmen, deren 
Hauptzweck in der raum-zeitlichen Transformation von Gütern besteht, ver- 
bunden mit der Integration sämtlicher Wechselwirkungen und Prozesse ent- 
lang der logistischen Kette. Für logistische Dienstleister besitzen Informa- 
tionen, insbesondere über die zu transportierenden Güter, eine große Be- 
deutung. Eine wesentliche Rolle spielen hierbei sendungsbezogene Orts- und 
Zustandsdaten sowie Auskünfte über potenzielle Veränderungen im vorge- 
sehenen Transport ablauf. Zu nennen sind hier (gegebenenfalls als Mehrwert- 
dienste) z. B. die Ermöglichung des Tracking (Verfolgung des aktuellen Trans- 
portverlaufes einschließlich der Bereitstellung von Statusdaten, Sendungsver- 
folgung) und des Tracing (Dokumentation des gesamten Transport Verlaufes). 
Voraussetzung hierfür ist ein Anwendungssystem, mit dessen Hilfe der Stand- 
ort (und Zustand) jedes Packstückes (Paket, Container usw.) zu gewissen 
Zeitpunkten ermittelt, über einen gewissen Zeitraum gespeichert und jeder- 
zeit abgefragt werden kann. 

Ein derartiges System kann auf unterschiedlichen Technologien aufbau- 
en. Weit verbreitet ist heutzutage die Verwendung von auf jedem Packstück 
befestigten Barcodes. Mittels Barcodelesegeräten kann dann an allen Schnitt- 
stellen des Transportes (d. h. bei jedem Lade- und Umladevorgang) kontrol- 
liert werden, welche Packstücke diese Schnittstelle in welchem Zustand passie- 
ren (d. h. gegebenenfalls können dabei auch Beschädigungen registriert wer- 
den). Dadurch wird für jedes Packstück ermittelt, in welchem Lager oder auf 
welchem Fahrzeug es sich befindet. Wird zusätzlich die Position der einzelnen 
Fahrzeuge mit Satellitenortungssystemen bestimmt, so sind genaue Angaben 
zum Standort eines Packstückes erhältlich, die dann dem Auftraggeber und 
dem Empfänger auf geeignete Weise zugänglich gemacht werden können. 

Das hier zum Einsatz kommende Anwendungssystem muss für die Sen- 
dungsverfolgung auf einer Datenbank aufsetzen, in der alle Lesevorgänge al- 
ler Barcodelesegeräte mit einem Zeitstempel versehen gespeichert werden. 
Darüber hinaus muss ein Zugriff auf die Auftragsdaten gewährleistet sein, 
um eine eindeutige Zuordnung von Barcodes zu Aufträgen (und damit zu 
Auftraggeber und Empfänger) zu ermöglichen. Des Weiteren muss ein derar- 
tiges System nicht nur eine aktuelle Sendungsverfolgung gewährleisten, son- 
dern auch die Möglichkeit bieten, zu einem späteren Zeitpunkt den Weg eines 
Packstückes nachvollziehen zu können (z.B. für den Fall eines Diebstahles). 
Aus rechtlichen Gründen muss oftmals auch der Zustand von Packstücken 
(Beschädigungen) dokumentiert werden, d. h. eine zusätzliche (manuelle) Ein- 
gabe von Schäden in das Anwendungssystem muss möglich sein. Darüber 
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hinaus muss gesichert sein, dass Daten über den Weg (und Zustand) eines 
Packstückes nicht im Nachhinein manipuliert werden können. 

7.5.3 Anwendungssysteme auf einem Containerterminal 

In Abschnitt 1.1 haben wir zur Verdeutlichung einiger der im Rahmen der 
integrierten Informationsverarbeitung eines Unternehmens auftretenden As- 
pekte das Beispiel eines Containerterminals der Hamburger Hafen und La- 
gerhaus AG betrachtet; vgl. http://www.hhla.de. Als Dienstleistungsunter- 
nehmen der Verkehrswirtschaft verwendet die HHLA dabei eine Vielzahl von 
integrierten IKS. Die Darstellung in Abbildung 7.11 symbolisiert vereinfacht 
das Zusammenspiel integrierter Planungs-, Kontroll- und Steuerungssysteme. 




Abbildung 7.11. Funktionsübersicht auf einem Containerterminal 



Ausgehend von einem zentralen IKS (dargestellt als zentraler Server) las- 
sen sich verschiedene Bereiche und die in ihnen ablaufenden Prozesse und 
Systeme auf einem Containerterminal planen, steuern sowie überwachen. 
Hiervon betroffen sind die Verkehrsträger Schiff, Bahn und LKW sowie die 
für den innerbetrieblichen Transport der Container verwendeten Portalhub- 
fahrzeuge (auch als Straddle Carrier oder Van Carrier bezeichnet) und die 
wasserseitigen (Verlade-)Brücken. Ein wesentlicher Aspekt ist dabei ein effi- 
zienter Daten- und Informationsaustausch, um z. B. die Avisen von Kunden 
bzw. Reedereien auf elektronischem Wege erhalten und weiter verarbeiten zu 
können. Damit Daten sowohl unternehmensweit als auch extern über geeigne- 
te Schnittstellen zur Verfügung stehen, kann man sich u. a. des elektronischen 
Datenaustausches mit Hilfe eines externen Dienstleisters bedienen (siehe Ab- 
schnitt 7.6.2). 

Diverse Anwendungssysteme unterstützen die verschiedenen Aufgaben- 
bereiche des Terminals. Das Umschlagsystem des Terminals gliedert sich je 
nach Verkehrsträger bzw. durchzuführenden Tätigkeiten in verschiedene Be- 
reiche. Die LKW- und die Bahnabfertigung stellen dabei die landseitige und 
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die Schiffsabfertigung die wasserseitige Schnittstelle des Systems dar. Die 
Schiffsabfertigung bezieht sich dabei wasserseitig auf verschiedene Schiffsar- 
ten mit unterschiedlichen Größen und Kapazitäten und landseitig auf die 
Brücken und Kräne zum Laden und Löschen von Containern, die ihrerseits 
durch Portalhubfahrzeuge bedient werden. Die angelieferten Container wer- 
den in einem Import-Export-Bereich (Yard) zwischengelagert. 

Wir beschreiben im Folgenden exemplarisch einige Aspekte der Liege- 
platzplanung; vgl. Hoffarth und Voß (1994). Um eine Liegeplatzdisposition 
durchführen zu können, sind im System die folgenden Daten vorzuhalten, 
wobei jeweils sowohl Stammdaten als auch Bewegungsdaten enthalten sind. 

• Schiffsdaten (Stamm-, Ankunfts- und Routendaten) 

hierzu gehören: Name des Schiffes, Schiffs-Code, Länge, Breite, Handlingre- 
striktionen (Angabe, ob es sich um ein Schiff mit speziellen Anforderungen 
handelt, z. B. Querstau^®), eta/ets (Estimated Time of Arrival, Estimated 
Time of Sailing), aktueller Tiefgang, Anzahl Lösch- und Ladecontainer 

• Brückendaten (Stamm- und Sperrungsdaten) 

hierzu gehören: Brücken-Nummer, Länge des Auslegers, Breite, Fahrbe- 
reich auf dem Terminal, Vorhandensein einer Drehkanzel (zur Bearbeitung 
von Schiffen mit Querstau), Sperrungsdaten (Dauer von/bis, Sperrungs- 
grund) 

• Liegeplatzdaten (Stamm- und Sperrungsdaten) 

hierzu gehören: Soll- Wassertiefe und Lage von Untiefen, Sperrungsdaten 
(Dauer von/bis, Sperrungsgrund) 

Darüber hinaus sind Daten aus der Yardplanung verfügbar (Stellplatz- 
daten der Container) sowie Angaben über die Entfernungen auf dem Yard 
in Form einer Distanzmatrix. Auf Basis der gegebenen Daten lassen sich 
Restriktionen formulieren, die für eine Liegeplatzdisposition von Bedeutung 
sind. Dies sind insbesondere ausschließende Nebenbedingungen (z. B. darf der 
aktuelle Tiefgang eines Schiffes nicht größer sein als die Wassertiefe des zuge- 
ordneten Liegeplatzes) sowie konkurrierende Nebenbedingungen (z. B. muss 
der Arbeitsbedarf gleichzeitig abzufertigender Schiffe mit der zur Verfügung 
stehenden Personal- und Gerätedecke zu bewältigen sein). Im Zuge der ei- 
gentlichen Liegeplatzdisposition ist jedem Schiff bei Ankunft ein Liegeplatz 
zuzuweisen; d. h. das Ziel ist die zweckmäßige Verteilung aller für einen Pla- 
nungszeitraum gemeldeten Schiffe auf die Kaianlagen des Terminals.^® 

Die Stauplanung betrifft die Planung und Steuerung der Beladung sowie 
des Löschens der Schiffe. Dabei werden für jedes Schiff unter Berücksichti- 
gung diverser Rahmenbedingungen geeignete Sequenzen fest gelegt, in welcher 
Reihenfolge z.B. Container geladen werden. 

Container werden normalerweise in Längsrichtung zum Schiff gestapelt. Im Falle 
einer Abweichung hiervon spricht man von Querstau. 

Unter Berücksichtigung der Zielsetzung, dass die Gesamtstrecke der im Planungs- 
zeitraum anfallenden Portalhubfahrzeug-Fahrwege zu minimieren ist, handelt es 
sich um ein AfP-schweres Problem; vgl. Abschnitt 2.1.2. 
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Als Anwendungssysteme auf einem Containerterminal können auch Si- 
mulationssysteme fungieren. So lässt sich beispielsweise der Umschlag auf 
einem Terminal modellhaft „durchspielen“; vgl. z. B. das System SCUSY.^° 
Simulatonssysteme können auch in Verbindung mit anderen Systemen ein- 
gesetzt werden. Als Beispiel sei ein Gefahrgut-Meldesystem genannt, welches 
als Kommunikationsverbund zwischen Unternehmen und Behörden sowie In- 
stitutionen der öffentlichen Hand wie Polizei und Feuerwehr den Datenaus- 
tausch bezüglich Registrierung von Gefahrgut durchführt. Die Auswirkungen 
eines Schadensfalles lassen sich in Verbindung mit dem Simulationssystem 
modellhaft eruieren. 



7.6 Electronic Commerce 

Unter Electronic Commerce (EC) versteht man die elektronische Abwicklung 
von Geschäftsverkehr („elektronisches Handeln“, „elektronische Märkte“), 
d.h. die (teil-)automatisierte Kommunikation (Informationsaustausch) von 
Unternehmen mit externen Partnern zur (elektronischen) Abwicklung von 
Transaktionen unter Einsatz von Informations- und Kommunikationstechnik. 
Dabei werden alle Phasen von Markttransaktionen unterstützt (Informati- 
ons-, Vereinbarungs- und Abwicklungsphase einschließlich Nachbehandlung). 

Eine elektronische Unterstützung solcher Transaktionen läuft letztendlich 
auf eine unternehmensübergreifende Integration von Informations- und Kom- 
munikationssystemen hinaus. Nur hierdurch können moderne Produktions-, 
Logistik-, und Supply-Chain-Management-Konzeptionen sinnvoll verwirk- 
licht werden. Der Zwang hierzu ergibt sich durch die Veränderungen der 
Wettbewerbsbedingungen, insbesondere im Zusammenhang mit der Globa- 
lisierung und einer weitergehenden Arbeitsteilung in allen Unternehmen- 
sprozessen mit einer Vervielfachung der Informationsprozesse. Voraussetzung 
für ein erfolgreiches Umsetzen von entsprechenden Potenzialen ist ein ganz- 
heitliches Prozessdenken über Unternehmensgrenzen hinweg und eine Un- 
terstützung durch entsprechende Informations- und Kommunikationstechnik. 
Ansätze hierzu sind schon seit den 1970er Jahren im Zusammenhang mit 
Konzeptionen des Electronic Data Interchange (EDI) vorhanden. 

Auf der Absatzseite ergeben sich neue Potenziale durch den Durchbruch 
des Internets bzw. WWW als Vertriebsweg. Hieraus resultiert ein verschärf- 
ter globaler Wettbewerb mit höherer Markttransparenz. Eine entsprechende 
Konzeption eines kundenorientierten Informationsmanagements ist die Vo- 
raussetzung für die erfolgreiche Etablierung entsprechender Systeme. Als 
etablierte Ansätze sind zur Zeit zu nennen: Electronic Banking, Software- 

Eine umfangreiche Darstellung des Systems SCUSY sowie weiterer Systeme, die 
u. a. auch für die HHLA eingesetzt werden bzw. wurden, findet sich unter http : 
//www. scusy . isl . org/ des Institutes für Seeverkehrswirtschaft und Logistik in 
Bremen. Zu einer umfassenden Literaturübersicht siehe Steenken et al. (2004). 
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Verteilung über das Internet, elektronische Kaufhäuser (z. B. Buchhandlun- 
gen), elektronische Marktplätze einschließlich Auktionsplattformen u. A. 

Die oben beschriebenen Entwicklungen erbringen neue Rationalisierungs- 
und Erfolgspotenziale, aber gegebenenfalls zunächst auch eine hohe Kom- 
plexität im Zusammenhang mit Konzeption, Entwicklung und Einsatz neuer 
Informations- und Kommunikationssysteme. Allen Entwicklungen gemeinsam 
ist aber der Zwang zur Übertragung von Daten zwischen Informationssyste- 
men. Eine Klassifizierung des EC kann u. a. bezüglich der beteiligten Parteien 
erfolgen: 

• Unternehmen zu Unternehmen (Business-to-Business (B2B), z.B. EC zwi- 
schen einem Unternehmen und seinen Lieferanten; man spricht hierbei auch 
von Electronic Procurement, d. h. elektronischer Beschaffung), 

• Unternehmen zu Verbrauchern (Business-to-Consumer (B2C), z.B. elekt- 
ronische Kaufhäuser im WWW), 

• Unternehmen zu Verwaltung (Business-to- Administration (B2A), z.B. im 
Zuge von Ausschreibungen von Projekten bzw. Anschaffungen der Verwal- 
tung). 

Der B2B-Commerce ist insbesondere durch eine Verbindung zwischen den be- 
teiligten Partnern entlang von Wertschöpfungsketten geprägt. Dagegen hat 
der B2C-Commerce in erster Linie kleinere Transaktionsvolumen und kurz- 
fristige Geschäftsbeziehungen als Merkmale. Weitere Klassifizierungsmöglich- 
keiten für EC bestehen u. a. hinsichtlich:^^ 

• Transaktionsphasen, 

• Tr ans aktions Volumen (Mikrotransaktionen bis ca. 5,00 €, Makrotransak- 
tionen ab ca. 5,00 €) 

• Softwarearchitektur (Kommunikationsebene, Darstellungsebene, Anwen- 
dungssystemebene) . 

Eine wichtige Grundbedingung für EC ist die Standardisierung von Kom- 
munikationsprotokollen und Sicherheitsmechanismen. Ersteres ist durch Nut- 
zung des Internets und der dortigen Standards verwirklicht. Die Standardisie- 
rung der für einen reibungslosen Electronic Commerce notwendigen Sicher- 
heitsmechanismen ist demgegenüber noch nicht abgeschlossen. Letztendlich 
muss derzeit davon ausgegangen werden, dass das Internet als Kommunika- 
tionsinfrastruktur unsicher ist. Hieraus ergibt sich direkt die Erfordernis für 
den Einsatz von Kryptographie auf Ende-zu-Ende-Basis; vgl. Abschnitt 7.2.3. 
Im Folgenden geben wir einige Hinweise zum elektronischen Zahlungsverkehr, 
zum EDI sowie zu elektronischen Marktplätzen.^^ 

Vgl. z. B. Merz (2002) und Wirtz (2002). Zu einer Übersicht zum EC siehe auch 
Shaw et al. (2000) sowie Fritz (2004). 

Dass darüber hinaus eine Vielzahl weiterer Schlagworte existieren, wie z.B. M- 
Commerce (für Mobile Commerce im Sinne einer Abwicklung des EC mittels 
Handy bzw. Mobilkommunikaton) oder E-Business zur Beschreibung des gesam- 
ten Feldes IT-basierter Geschäftsstrategien, zeigt, dass die Wirtschaftsinformatik 
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7.6.1 Elektronischer Zahlungsverkehr 

Unter elektronischem Zahlungsverkehr versteht man die gesamte Palette der 
Erfüllung von Finanzdienstleistungen auf elektronischem Wege. Die verschie- 
denen Parteien im Zusammenhang mit elektronischem Zahlungsverkehr las- 
sen sich wie folgt klassifizieren: 

• Nachfrager/Käufer, 

• Anbieter von Finanzdienstleistungen (z.B. Banken), 

• Organisatoren des Zahlungssystems/Ubertragungsmediums, 

• Anbieter/Verkäufer. 

Mögliche Anforderungen an Systeme für einen elektronischen Zahlungs- 
verkehr sind Z.B.: 

• Sicherstellung der Geheimhaltung und Integrität des Daten- und Zahlungs- 
verkehrs 

• Beweisbarkeit von Transaktionen 

• Datenschutz (Vertraulichkeit, Anonymität) 

• rechtliche Anerkennung, gerechte Verteilung der Risiken 

• steuerliche Erfassbarkeit, währungspolitische Kontrollierbarkeit 

• gesellschaftliche Akzeptanz (Benutzerfreundlichkeit, Sicherheit u. a.) 

• internationale Standards 

Zur Zeit existiert noch kein diesen Anforderungen gerecht werdendes uni- 
verselles System. Deshalb werden im Weiteren verschiedene Formen bzw. 
Konzepte des elektronischen Zahlungsverkehrs skizziert. 

Systeme des Home-Banking über Online-Dienste oder das Internet sind 
in der Regel nur als Ersatz für den Zahlungsverkehr Kunde-Bank zu verste- 
hen und bieten zunächst keine erweiterte Funktionalität im Hinblick auf die 
Unterstützung von EC- Anwendungen. Beim Home-Banking sind verschiede- 
ne Sicherheitskonzepte im Einsatz wie z.B. das SSL-Protokoll, die Übertra- 
gung von Daten mit elektronischen Signaturen, der Kontozugang über PIN 
und TAN (persönliche Identifikationsnummer und Transaktionsnummer) so- 
wie Firewalls zur Sicherung der Informations- und Kommunikations-Infra- 
struktur von am Zahlungsverkehr beteiligten Parteien. 

Bei der elektronischen Bezahlung per Kreditkarte ergibt sich zum einen 
die Problematik einer geheimen Übertragung der Kreditkartennummer, aus 
Anbietersicht die Erfordernis einer Nachprüfbarkeit entsprechender Transak- 
tionen, sowie aus Nachfragersicht auch die Notwendigkeit der Überprüfung 
der Authentizität des Anbieters (um Scheinanbieter auszuschließen). In die- 
sem Zusammenhang ist etwa die SET-Spezifikation (SET: Secure Electronic 

an dieser Stelle noch wesentliche Aufgaben besitzt. Diese sollten sich aber nicht 
auf das Hinterherlaufen hinter aktuellen Moden beschränken. 

Vgl. z.B. Buchholz-Stepputtis und Voß (1999) sowie die dort angegebene Lite- 
ratur. 
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Transaction) zu nennen, wodurch eine sichere Zahlungsabwicklung für das In- 
ternet ermöglicht werden sollte. Die Kreditkarteninformationen des Nachfra- 
gers werden dabei verschlüsselt gespeichert und übertragen; weiterhin werden 
über Authentifizierungs-Server die Identitäten der beteiligten Geschäftspart- 
ner überprüft. Wichtig ist dabei, dass der Zahlungs Vorgang unabhängig vom 
Bestellvorgang abgewickelt wird. SET hat sich in der Praxis jedoch nicht 
durchgesetzt. 

Die originäre Zielsetzung beim elektronischen Bargeld besteht darin, die 
Funktionalität von Geld elektronisch in dem Sinne nachzubilden, dass eine 
Bezahlung ohne Vermittlerinstanz möglich ist („privat an privat“ /„peer to 
peer payment“). Dies würde auch die effiziente Bezahlung kleinster Geldbe- 
träge im Internet ermöglichen; ein Beispiel hierfür wäre der Zahlungspflichtige 
Zugriff auf einzelne elektronische „Zeitungsartikel“. 

Abschließend sei kurz die Option der Speicherung von Geldbeträgen auf 
Chipkarten oder Smartcards erwähnt. Der eingeführten ec-Karte mit Ghip 
liegen Spezifikationen des zentralen Kreditausschusses (ZKA) zu Grunde. 

7.6.2 Elektronischer Geschäftsdatenaustausch 

EDI, d.h. Electronic Data Interchange, steht für eine zwischenbetriebliche, 
strukturierte Kommunikationsform zum Austausch von codierten Informa- 
tionen mit speziflzierbarer Semantik. Einem weitgehenden Durchbruch stand 
bisher das Fehlen einer einfachen und effizienten Kommunikationsinfrastruk- 
tur sowie eine hohe Komplexität und Vielfalt bezüglich Formaten zum Da- 
tenaustausch entgegen. Als Vorteile sind u. a. die Reduktion administrativen 
Aufwandes durch Automatisierung kostenintensiver Arbeitsprozesse, Ratio- 
nalisierung, erhöhte Daten- und Informationsqualität sowie eine Verbesserung 
des Informationsflusses (z. B. durch Synchronisation) zu nennen. 

Ein Problem der ersten Ansätze zur Standardisierung von elektronischem 
Datenaustausch zwischen Unternehmen war, dass unterschiedliche Branchen 
unterschiedliche Anforderungen an den Datenaustausch und damit an einen 
EDI-Standard stellten. EDIFAGT (EDI For Administration, Gommerce and 
Transport) ist eine Erweiterung von EDI, die betriebswirtschaftliche Infor- 
mationen im elektronischen Geschäftsverkehr zwischen Marktpartnern for- 
malisiert und die Migration von nationalen branchenbezogenen Standards zu 
einem internationalen branchenübergreifenden Standard darstellt. 

Die Basis von EDI-Lösungen bilden Referenzmodelle für die elektroni- 
sche Kommunikation offener Systeme. In Abbildung 7.12 ist ein prinzipielles 
Ablaufmodell von EDI dargestellt. EDI bildet eine Zwischenschicht zwischen 
Anwendungen und den zu Grunde liegenden Datenbasen auf der einen und 
dem Datenfernübertragungs-Bereich (DFÜ) auf der anderen Seite. Eine Ar- 
chivierung der Nachrichten erfolgt an allen Schnittstellen, an denen Fehler 
auftreten können, d. h. es werden alle Daten archiviert, die einen Bereich 
verlassen, bzw. in einem Bereich ankommen. Integrale Bestandteile des EDI- 
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Bereiches bilden ein Umsetzungsmodul zur Konvertierung der Daten und ein 
Modul zur Verschlüsselung der zu sendenden Daten (Kryptographie) . 
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Abbildung 7.12. EDI-Ablaufmodell; Quelle: Miebach und Schneider (1994), S. 561 



Abschließend greifen wir erneut unser Beispiel eines Containerterminals 
im Hamburger Hafen auf. Eine mögliche EDI-Lösung stellt das System HA- 
BIS (Hafenbahn-Betriebs- und Informationssystem) der DAKOSY GmbH 
dar.^"*^ Dieses System verbindet die EDV-Systeme der Seehafenverkehrswirt- 
schaft mit denen der Deutschen Bahn AG und ermöglicht einen schnellen 
und reibungslosen Informationsfluss zwischen den Kunden der Bahn einer- 
seits (Spediteure, Linienagenten, Reeder) sowie den Be- und Entladestellen 
andererseits (Kaibetriebe etc.). Zielsetzung ist, alle Funktionen der Trans- 
portdisposition und -abwicklung zeitsparend und transparent abzuwickeln. 
Im Transportprozess müssen die Informationen der physischen Transportket- 
te möglichst vorauseilen, um jederzeit verfügbar zu sein. Die DAKOSY GmbH 
hat hier die Aufgabe einer Schnittstelle, um alle in die Umschlagprozesse in- 
volvierten Unternehmen und Institutionen im Zuge des EDI miteinander zu 
verknüpfen. Einheitliche Schnittstellen sorgen dafür, dass jedes Unternehmen 
die EDI-Schnittstelle zum DAKOSY-System nur einmal realisieren muss und 
dann die Gesamtheit aller DAKOSY-Teilnehmer erreichen kann. Sämtliche 
transportrelevanten Dokumente können über die verschiedenen Systeme mit- 
tels einer einheitlichen Semantik ausgetauscht werden. 

WebEDI als spezielle Ausprägung des EDI wurde mit dem Ziel entwickelt, 
einen WWW-basierten Geschäftsdatenaustausch zu ermöglichen, damit auch 
mittelständische Betriebe in die Lage versetzt werden, Transaktionen elekt- 
ronisch abzuwickeln. Dabei erfolgt eine Umsetzung von EDI-Nachrichten in 
HTML-Formulare. Dieses Modell ist besonders geeignet, wenn das Volumen 

Vgl. http://www.dakosy.de. Neben HABIS werden von DAKOSY eine Vielzahl 

weiterer Systeme und Anwendungen betrieben. 
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an EDI-Nachrichten auf einer Seite der beteiligten Unternehmen relativ ge- 
ring ist und weder in günstiger Relation zu den Investitionen in ein vollständi- 
ges EDI-System noch zu den Kosten der Anbindung an ein Clearing Center 
steht. 

Nachteil des WebEDI gegenüber dem herkömmlichen EDI ist gegebenen- 
falls der Verlust einer auf Basis der vorliegenden semantischen Informatio- 
nen gegebenen Weiter Verarbeitbarkeit auf Seiten eines der Beteiligten. Ei- 
ne mögliche Kombination der Vorteile von EDI (Automatisierbarkeit) und 
WebEDI (Einfachheit) findet sich im Konzept des XML-EDI, das auf der 
(Meta-)Auszeichnungssprache XML basiert. Die hiermit ermöglichte Definiti- 
on von semantischen Strukturen innerhalb von Dokumenten zur Repräsenta- 
tion entsprechender Informationen erlaubt eine vollständige Automatisierung 
der entsprechenden Transaktionsabwicklungen. Als Problem bleibt letztlich 
die Frage nach der Standardisierung von Nachrichtentypen bzw. der Verant- 
wortlichkeit dafür. 



7.6.3 Elektronische Märkte 

Elektronische Märkte entstehen durch die Mediatisierung von Markttransak- 
tionen, d. h. die elektronische Abbildung von Informations- und Kommunika- 
tionsbeziehungen auf Märkten. Damit ist ein elektronischer Markt ein IKS zur 
Unterstützung einzelner oder aller Phasen und Funktionen der marktmäßig 
organisierten Leistungskoordination. Während wir in der Einleitung zu Ab- 
schnitt 7.6 EC an sich betrachtet hatten, fassen wir hier elektronische Märkte 
bzw. Marktplätze als „Enabler“ für das EC auf. 

Basierend auf der Bildung elektronischer Märkte entstehen neue Dienst- 
leistungen sowie Intermediäre, d. h. Mittler, und Clearing Center, d. h. In- 
formationsbetriebe zur Koordination von Marktaustausch- und Kommuni- 
kationsprozessen. Mar kt Veranstaltungen und Handelsmittler sind auch auf 
elektronische Märkten erforderlich, um gegebenenfalls den Austausch von 
Leistungen zwischen Marktteilnehmern zu ermöglichen. Elektronische Märk- 
te und Marktteilnehmer schaffen einen organisatorischen Rahmen, innerhalb 
dessen Veranstaltungen bzw. Mechanismen wie Auktionen, Börsen oder an- 
dere Online-Dienste ablaufen können. 

Verschiedene Transaktionsphasen lassen sich gegebenenfalls vollständig 
durch Informations- und Kommunikationstechnik abbilden. Das Beispiel 
automatisierter Einkaufs- und Bestellsysteme (Electronic Procurement) 
weist dabei für den B2B-Bereich Ähnlichkeiten zu automatisierten Wa- 
renwirtschaftssystemen auf. Auf Basis moderner IT ermöglichen elektroni- 
sche Märkte gegebenenfalls geringe Koordinations- und Transaktionskosten. 
Darüber hinaus können Intermediäre Mehrwertdienste anbieten, die z. B. in 
der Integration verschiedener Quellen, Daten oder Informationen bestehen 
können. Ein Beispiel für derartige Integrationsfunktionalität bieten Reser- 
vierungssysteme von Fluggesellschaften, deren Datenbestände kontinuierlich 
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mit Revenue-Management-Systemen abgeglichen werden können; vgl. Ab- 
schnitt 7.4.3. Weitere Beispiele sind Online-Börsen; aber auch geschlosse- 
ne Handelssysteme wie z. B. virtuelle Organisationen können elektronische 
Märkte definieren. Abbildung 7.13 zeigt mögliche Beziehungen beteiligter Ak- 
teure am EC auf. 




Abbildung 7.13. Beteiligte Akteure am Electronic Commerce; Quelle: Voß und 
Gutenschwager (2001), S. 398 



7.7 Übungen und Kontrollfragen 

1. Nennen Sie wesentliche Faktoren, die für den Kauf einer Standard- 
software von Bedeutung sein können! Veranschaulichen Sie Ihre 
Überlegungen z.B. anhand der Entscheidung für den Einkauf eines 
Simulationssystems ! 

2. Geben Sie zu einigen der in Abbildung 7.2 auf Seite 216 erwähnten 
Systeme stichwortartig eine kurze Erläuterung anhand des Beispieles 
eines Busreiseunternehmens! 

3. Sie haben das RS A- Verfahren als ein asymmetrisches Verschlüsselungs- 
verfahren kennen gelernt. Es sei angenommen, dass Sie das RSA- 
Verfahren nutzen und sich folgende Schlüssel erzeugt haben: 

• public-key (n, e) = (21, 17) 

• secret-key (n,d) = (21,5) 

Weiterhin kennen Sie den public-key Ihres Freundes Bob: 
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• public-keyBob {n, e) = (65, 7) 

Bob schickt Ihnen, als einem ausgewiesenen Primzahlexperten, verschlüs- 
selt eine Zahl, die Sie dahingehend überprüfen sollen, ob die Zahl die 
Primzahleigenschaft besitzt. Sie erhalten von Bob die Nachricht c = 11. 
Mit Bob haben Sie ausgemacht, dass Sie ihm die Antwort folgenderma- 
ßen zuschicken: 1, falls Bobs Zahl keine Primzahl ist, bzw. 2, falls Bobs 
Zahl eine Primzahl ist. Diese Information ist allerdings bei dem Versen- 
den an Bob zu verschlüsseln. Berechnen Sie die an Bob zu schickende 
verschlüsselte Nachricht! 
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A.l Historie der Wirtschaftsinformatik 

Versucht man, kurz die Geschichte der Wirtschaftsinformatik zu beschrei- 
ben, so stellt sich die Frage, wie weit man zurückgehen möchte. Im Bereich 
der Entwicklung des Computers mag man hier bereits im 17. Jahrhundert 
bei Pascal und Leihniz einfache Rechenmaschinen finden; oder man denkt 
an die Lochkartenverarbeitung von Hollerith und die Entstehungsgeschichte 
einfacher Rechner bei Zuse und von Neumann. Auf der anderen Seite haben 
wir die Kommunikation mit bahnbrechenden Ideen und Konzepten etwa von 
Morse, Reis und Bell. 

Letztendlich stellt man fest, dass die Wirtschaftsinformatik als relativ jun- 
ge Fachdisziplin viele Quellen und Ursprünge hat. Sie entstand insbesondere 
aus frühen Ansätzen zur Einführung und Nutzung automatisierter elektroni- 
scher Datenverarbeitung in Betrieben in den 1950er und 1960er Jahren. Un- 
ter elektronischer Datenverarbeitung versteht man die automatische elektro- 
nische Verarbeitung (Erfassung, Speicherung, Transformation, Übertragung) 
von Daten, in der Regel mit Computern. Aus diesen Systemen entwickelte sich 
die integrierte Informationsverarbeitung zur Unterstützung betrieblicher In- 
formationsprozesse. Das Fachgebiet Wirtschaftsinformatik (älteres Synonym: 
Betriebsinformatik) befasst sich seither mit den dabei auftretenden, inhärent 
komplexen Problemen.^ 

Die ersten Universitätslehrstühle in diesem Fachgebiet wurden Ende 
der 1960er bzw. Anfang der 1970er Jahre gegründet (unter Bezeichnun- 
gen wie z.B. „Betriebswirtschaftliches Institut für Organisation und Au- 
tomation“ oder „Betriebswirtschaftliche Datenverarbeitung“). Mitte der 
1970er Jahre entstanden im deutschsprachigen Raum darüber hinaus ers- 
te Wirtschaftsinformatik-Studiengänge. 1975 wurde eine wissenschaftliche 
Kommission „Betriebsinformatik“ im Verband der Hochschullehrer für Be- 

^ Eine kurze Darstellung zur Geschichte der Wirtschaftsinformatik findet sich z. B. 
in Mertens (1998). Um die Herkunft und Entwicklung der Wirtschaftsinformatik 
nachvollziehen zu können, lohnt es sich auch, in die früheren Auflagen bekannter 
Lehrbücher zu schauen (z. B. die ersten Auflagen der Bücher von Scheer (1990a) 
aus dem Jahre 1984 bzw. Scheer (1997) aus dem Jahre 1988, bei dem auch eine 
Veränderung des Untertitels von „Informationssysteme im Industriebetrieb“ hin 
zu „Referenzmodelle für industrielle Geschäftsprozesse“ erfolgte. 
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triebswirtschaft (die spätere WKWI) gegründet; ein entsprechender Fach- 
bereich „Informatik in der Wirtschaft“ in der Gesellschaft für Infor- 
matik entstand 1983. 1981 erschien die I. Auflage des Studienführers 
Betriebs- und Wirtschaftsinformatik. Die Hochschulausbildung Betriebsinfor- 
matik/Wirtschaftsinformatik wurde in den 1980er Jahren in Anforderungs- 
profllen fest gelegt und mündete 1991 in eine Rahmenempfehlung für Diplom- 
studiengänge Wirtschaftsinformatik an Universitäten. Das erste Jahrzehnt 
des 21. Jahrhunderts ist hinsichtlich der Hochschulausbildung in Deutschland 
im Wesentlichen durch die Umstellung der Diplomstudiengänge auf Bachelor- 
und Master- Abschlüsse geprägt. 



A.2 Wissenschaftstheoretische Einordnung 

Was heißt „Wissenschaft“ überhaupt? Die Wissenschaftstheorie stellt Wis- 
senschaft an sich, bzw. spezielle Wissenschaftsgebiete, als Untersuchungs- 
gegenstand in den Mittelpunkt der Betrachtung. Wissenschaftstheorie kann 
demzufolge auch als Metawissenschaft bezeichnet werden. 

Es gibt offensichtlich gewisse Kriterien der Wissenschaftlichkeit, die mehr 
oder weniger bewusst zu Grunde gelegt werden. Beispielsweise wird man 
implizit u. a. etwa folgende Ansprüche an eine wissenschaftliche Ausarbei- 
tung stellen: Grundbegriffe sollten hinreichend bestimmt sein; Problemstel- 
lungen sollten klar beschrieben sein; die zu untersuchenden Sachverhalte sol- 
len in Ihrer ganzen Komplexität betrachtet werden, d. h. wesentliche Aspekte 
dürfen nicht vernachlässigt werden; Aussagen sollen die bekannten Tatsachen 
berücksichtigen; die Argumentationen sollten konsistent und nachvollziehbar 
sein usw. Um solche und ähnliche Aspekte der Zielbildung, Begriffsbestim- 
mung, Hypothesenprüfung, Theorienbildung und Argumentationsweise geht 
es in der Wissenschaftstheorie. Im Folgenden werden einige hier relevante 
Aspekte der Wissenschaftstheorie angesprochen. ^ 

Wissenschaften werden oft als Real- oder als Formalwissenschaft klassifi- 
ziert. Während der Untersuchungsgegenstand einer Realwissenschaft primär 
Phänomene der Wirklichkeit, bzw. entsprechender Ausschnitte, sind, basieren 
Formalwissenschaften auf prinzipiellen, abstrakten Strukturen. So kann man 
die Mathematik im Wesentlichen als Formalwissenschaft einordnen, während 
die Betriebswirtschaftslehre eine Realwissenschaft darstellt. Ingenieurwissen- 
schaften zeichnen sich durch die noch weitergehende Anwendungsorientierung 
aus: Ziel ist die „Produktion“ nutzenstiftender Artefakte durch Weiterbil- 
dung und Anwendung wissenschaftlicher Erkenntnisse. Zumeist sind solche 
Einordnungen weder eindeutig noch disjunkt. So wird die Informatik teilweise 
als Ingenieurwissenschaft auf formal wissenschaftlicher Grundlage bezeichnet. 

^ Für tiefergehende Darstellungen wird auf die Literatur, z. B. Büttemeyer (1995) 
bzw. die dortigen Referenzen, verwiesen. 
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Wie unten deutlich werden wird, ist die Einordnung der Wirtschaftsinforma- 
tik entsprechend problematisch. 

Die im Rahmen einer Wissenschaft angewandten Methoden können 
primär klassifiziert werden in axiomatisch-deduktiv (Aufstellen widerspruchs- 
freier Axiome und formales Ableiten neuer Aussagen durch Anwendung ent- 
sprechender Methodiken) und empirisch-induktiv (Sammeln von nachvoll- 
ziehbaren quantitativen und qualitativen Erfahrungen über einen Wirklich- 
keitsausschnitt und induktive Verallgemeinerung). 

Weiterhin können Ansätze hinsichtlich des verfolgten Anspruches folgen- 
dermaßen klassifiziert werden: deskriptiv (beschreibend), kritisch-deskriptiv 
(beschreibend einschließlich problematisierend durch Aufzeigen von Unzu- 
länglichkeiten) und normativ (Ziehen von Schlussfolgerungen einschließlich 
wertender Handlungsempfehlungen) . 

Weitergehende Untersuchungsgegenstände der Wissenschaftstheorie sind 
u. a.: Wie entwickelt sich wissenschaftlicher Erkenntnisfortschritt? Was sind 
Kriterien der Bewährung von Theorien? Wo liegen die Grenzen wissenschaft- 
licher Erkenntnis? Wie wird der Wert und Nutzen einer Wissenschaft ein- 
geschätzt? 

Betrachtet man die oben gegebene Definition „Die Wirtschaftsinformatik 
beschäftigt sich mit Informations- und Kommunikationssystemen in Wirt- 
schaft und Verwaltung; sie befasst sich dementsprechend mit der Konzeption, 
Entwicklung, Einführung, Wartung und Nutzung von Systemen der compu- 
tergestützten (betriebswirtschaftlichen) Informationsverarbeitung“, so ist der 
Untersuchungsgegenstand der Wirtschaftsinformatik definiert. Gemäß dieser 
Bestimmung wäre die Wirtschaftsinformatik im Wesentlichen als Ingenieur- 
wissenschaft zu bezeichnen.^ In diesem Zusammenhang stellt sich die Frage, 
ob der Wirtschaftsinformatik überhaupt der Rang einer eigenständigen Wis- 
senschaft oder Wissenschaftsdisziplin zugebilligt werden kann. Besitzt die 
Wirtschaftsinformatik überhaupt originäre Theorien und Methodiken, die 
über die Anwendung von Erkenntnissen der Informatik im festgelegten An- 
wendungsbereich hinausgehen? Doch anders als für die Studiengänge Wirt- 
schaftsingenieurwesen gibt es im Bereich Wirtschaftsinformatik dementspre- 
chend betitelte Lehrveranstaltungen, Lehrbücher und Lehrstühle. 

Nach der heute, teilweise implizit, vorherrschenden Meinung zeichnen sich 
Informations- und Kommunikationssysteme in Wirtschaft und Verwaltung 
durch eine hohe Komplexität aus, die die eigenständige Behandlung durch 
eine Wissenschaft Wirtschaftsinformatik rechtfertigt. Zum Teil mag dies an 
der eher theoretisch ausgerichteten Informatik liegen, die anwendungsnahe 
Probleme zu sehr vernachlässigt. Die WKWI umgeht eine klare Einordnung 
der Wirtschaftsinformatik folgendermaßen: 

® Im Gegensatz dazu wird in der wissenschaftlichen Literatur die Wirtschaftsin- 
formatik zum Teil nur den Realwissenschaften zugeordnet; vgl. Heinrich (2001) 
sowie Lehner (1995). 
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„Die Wirtschaftsinformatik ist eine Real Wissenschaft, da Phäno- 
mene der Wirklichkeit (,in Wirtschaft und Verwaltung‘ ) unter- 
sucht werden. Die Wirtschaftsinformatik ist ebenso eine Formalwis- 
senschaft, da die Beschreibung, Erklärung, Prognose und Gestal- 
tung der Informations- und Kommunikationssysteme der Entwick- 
lung und Anwendung formaler Beschreibungsverfahren und Theori- 
en bedürfen. Die Wirtschaftsinformatik ist weiterhin eine Ingenieur- 
wissenschaft, da insbesondere die Gestaltung von Informations- und 
Kommunikationssystemen in Wirtschaft und Verwaltung eine Kon- 
struktionssystematik verlangt.“ (WKWI (1994), S. 81) 

Ziel und Zweck der Untersuchungen der Wirtschaftsinformatik als Wis- 
senschaft ist gemäß der WKWI 

„[...] die Gewinnung von Theorien, Methoden, Werkzeugen und 
intersubjektiv nachprüfbaren Erkenntnissen über /zu Informations- 
und Kommunikationssystemen in Wirtschaft und Verwaltung und die 
Ergänzung des ,Methoden- und Werkzeugkastens‘ der Wissenschaf- 
ten um solche der Wirtschaftsinformatik, die den soziotechnischen 
Erkenntnis- und Gestaltungsgegenstand einer wissenschaftlichen Un- 
tersuchung zugänglich machen.“ (WKWI (1994), S. 81) 

In diesem Zusammenhang stellt sich die Frage: „Brauchen wir eine Theo- 
rie (bzw. ein ,Theoriengebäude‘ ) der Wirtschaftsinformatik?“ Lehner (1995) 
nimmt dazu wie folgt Stellung: 

„Aller Voraussicht nach wird es ,die‘ Theorie der Wirtschaftsinfor- 
matik nicht geben. Dies liegt zunächst an der Aufteilung in Teildiszi- 
plinen, die z. T. nur eine geringe Überschneidung aufweisen und die 
sich in ihren Zielen stark unterscheiden. Ursachen sind aber auch in 
den unterschiedlichen Forschungsansätzen zu sehen, die sich in ihrer 
methodologischen Grundausrichtung und in ihrer Orientierung z. T. 
wesentlich unterscheiden. [. . .] Theorien, die in der Wirtschaftsin- 
formatik eine Rolle spielen, sind u. a.: die Systemtheorie, die Modell- 
theorie, mathematische Theorien [...], die Informationstheorie (Sicht 
der Informatik und der Betriebswirtschaftslehre) sowie verschiedene 
betriebswirtschaftliche Theorien [...].“ (Lehner (1995), S. 10) 

Es ist zu konstatieren, dass die Wirtschaftsinformatik als relativ jun- 
ge Wissenschaft ein schwach ausgeprägtes theoretisches Grundlagengebäude 
besitzt. Die wissenschaftstheoretische Fundierung der Wirtschaftsinformatik 
muss damit als ständige Aufgabe angesehen werden und bedingt somit auch 
eine kritische Auseinandersetzung mit den hier unter dem Titel „Grundlagen 
der Wirtschaftsinformatik“ dargelegten Inhalten. 
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A.3 Gesellschaften 

Entsprechend der interdisziplinären Ausrichtung der Wirtschaftsinformatik 
werden Fragen der Wirtschaftsinformatik u. a. in den folgenden Organisatio- 
nen behandelt: 

• International Federation for Information Processing (IFIP) 

http : //www. if ip . or . at 

• Gesellschaft für Informatik e.V. (Gl), Fachbereich 5 (Wirtschaftsinforma- 
tik) 

http : // WWW . gi- e V . de 

• Wissenschaftliche Kommission Wirtschaftsinformatik (WKWI) im Ver- 
band der Hochschullehrer für Betriebswirtschaft e.V. 

http : //www .v-h-b.de/ 

• Association for Gomputing Machinery (AGM) 

http : // WWW . acm . org 

• Institute for Operations Research and the Management Sciences (IN- 
FORMS) 

http : // WWW . inf orms . org 

Die Gesellschaft für Informatik e. V. wurde 1969 in Bonn mit dem Ziel 
gegründet, die Informatik zu fördern. Ihre Mitglieder kommen aus allen Be- 
reichen der Wissenschaft, der „Informatikindustrie“, der Anwendungen so- 
wie der Ausbildung und Lehre. Die GI verfolgt gemeinnützige Ziele, indem 
sie insbesondere die fachliche und berufliche Arbeit von Informatikern un- 
terstützt. Dies erfolgt vornehmlich durch die Herausgabe und Förderung von 
Fachpublikationen sowie die aktive Mitwirkung im Vorfeld politischer Pla- 
nung und Gesetzgebung zur Forschungs-, Bildungs- und Technologiepolitik 
einschließlich der Abgabe von öffentlichen Empfehlungen und Stellungnah- 
men zur Informatik. Hierzu gehört auch die Veranstaltung von Tagungen, 
Kongressen etc. auf verschiedenen Ebenen sowie eine Mitarbeit bei der Defi- 
nition von Normen und Standards. Darüber hinaus erfolgt eine Förderung des 
wissenschaftlichen Nachwuchses sowie von in der Informatik tätigen Frauen 
mit dem Ziel ihrer faktischen Gleichstellung. 

Auf internationaler Ebene ist die GI Mitglied in der International Fe- 
deration for Information Processing. Bei der IFIP handelt es sich um ei- 
ne maßgebliche nichtstaatliche gemeinnützige Dachorganisation für nationale 
Gesellschaften auf dem Gebiet der Informationsverarbeitung. Auf nationaler 
Ebene unterteilt sich die GI u. a. in Fachbereiche und Regionalgruppen. Die 
Fachbereiche mit ihren Fachgruppen sind die vornehmlichen Träger der wis- 
senschaftlich fundierten Arbeit. Demgegenüber dienen die Regionalgruppen 
der Vernetzung und Unterstützung von in der Informatik Tätigen. 

Die Wirtschaftsinformatik findet sich im Fachbereich 5 der GI wieder und 
ist in diverse Fachgruppen und Arbeitskreise in den Bereichen Methoden, 
Vorgehen und Werkzeuge sowie Branchen und (Querschnitts-)Funktionen un- 
tergliedert. Zu den Fachgruppen gehören insbesondere solche, die sich mit 
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Informationssystemen in verschiedenen Bereichen, mit Projektmanagement 
und Vorgehensmodellen sowie Informationssystemarchitekturen (Modellie- 
rung betrieblicher Informationssysteme) befassen. Darüber hinaus werden 
Themen wie z. B. Electronic Commerce oder betriebliche Umweltinformati- 
onssysteme in eigenen Fachgruppen aufgegriffen. 

Im angelsächsischen Sprachraum gibt es eine Reihe von Gesellschaften mit 
großer internationaler Verbreitung. Die Association for Computing Machin- 
ery wurde 1947 gegründet und ist „the world’s oldest and largest educational 
and scientific Computing society“ mit einer Verbreitung von mehr als 80.000 
Mitgliedern in über 100 Staaten. Der primäre Fokus liegt dabei auf dem Vor- 
anbringen der „arts, Sciences, and applications of information technology.“ 
Das Institute for Operations Research and the Management Sciences mit ei- 
ner Reihe von Unterorganisationen (einschließlich einer eigenen Computing 
Society) befasst sich umfassend mit dem Operations Research und liefert so- 
mit wertvolle Diskussionspunkte zur methodischen Fundierung insbesondere 
auch der Wirtschaftsinformatik. 

Die Wissenschaftliche Kommission Wirtschaftsinformatik, deren 
grundsätzliche Definitionen wir oben bereits diskutiert haben, versteht sich 
als die Interessenvertretung der Wirtschaftsinformatiker und der Wirtschafts- 
informatik an Universitäten in den deutschsprachigen Ländern. Darüber 
hinaus gibt es den Arbeitskreis Wirtschafisinformatik an Fachhochschulen 
(AKWI) (http://www.akwi.de) als Dachverband der Fachhochschulfach- 
bereiche mit deutschsprachigen Wirtschaftsinformatik-Studiengängen oder 
entsprechenden Studienschwerpunkten . 



A.4 Publikationsorgane und Tagungen 

In diesem Buch werden wesentliche Themengebiete (z.T. überblicksartig) 
angesprochen, die mit der Konzeption, der Entwicklung und dem Betrieb 
von Informations- und Kommunikationssystemen (als Gegenstand der Wirt- 
schaftsinformatik) Zusammenhängen bzw. eine Voraussetzung für eine ent- 
sprechende, fundierte Auseinandersetzung darstellen. Natürlich verhehlen wir 
nicht, dass es zur Wirtschaftsinformatik eine Reihe weiterer einführender 
Lehrbücher mit unterschiedlichen Schwerpunkten gibt. Hierzu sind u. a. die 
folgenden zu nennen: 

• Ferstl und Sinz (2001), 

• Hansen und Neumann (2005), 

• Mertens et al. (2005), 

• Stahlknecht und Hasenkamp (2005) mit einem dazugehörigen Übungsbuch 
Stahlknecht und Hasenkamp (2003). 

Aktueller Studienführer für Wirtschaftsinformatik ist Mertens et al. 
(2002). Er enthält neben einigen allgemeinen Hinweisen zum Umfeld der 
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Wirtschaftsinformatik insbesondere eine umfassende Darstellung der Lehr- 
angebote an deutschsprachigen Universitäten. 

Der Stand der Wissenschaft sowie dessen praktische Umsetzung lässt sich 
insbesondere periodisch erscheinenden Zeitschriften sowie Tagungsbänden 
entnehmen. Im Folgenden seien einige klassische Zeitschriften im Bereich 
Wirtschaftsinformatik genannt: 

• Wirtschaftsinformatik (Organ des Fachbereiches 5 der Gl und der WKWI 
im Verband der Hochschullehrer für Betriebswirtschaft e.V.): „Gegenstand 
der Zeitschrift sind Forschungsergebnisse im Bereich der Wirtschaftsinfor- 
matik und Praxisbeispiele von fortschrittlichen Anwendungen. Konkrete 
Lösungen für technologiegestützte Anwendungssysteme werden nur dann 
publiziert, wenn sie Modellcharakter auch für andere Anwendungen besit- 
zen. Wichtige Randgebiete werden ebenfalls abgedeckt, soweit die Entwick- 
lungen im Bereich der engeren Wirtschaftsinformatik wesentlich betroffen 
sind; Beispiele hierfür sind die Wirkung der Informatik auf Wirtschaft, In- 
dividuum und Gesellschaft sowie Fragen der Aus- und Weiterbildung. Die 
Zeitschrift wendet sich an Leser in Wissenschaft und Praxis, die auf dem 
Gebiet der Wirtschaftsinformatik arbeiten. Besonders sind auch Studieren- 
de und andere Personen angesprochen, die den Anschluss an die modernen 
Entwicklungen in diesem Fach suchen.“ 

• HMD - Praxis der Wirts chafisinformatik: Die HMD befasst sich mit In- 
formationstechnologie und -management „mit viel Praxisbezug und dem 
notwendigen theoretischen Hintergrund wissen. Softwareangebot und Soft- 
ware Engineering, Projektmanagement, Business Engineering, Hardware, 
Rechner- und Netzwerkarchitekturen, Anwendungen in den verschiedenen 
Funktionsgebieten und Branchen, aktuelle Probleme in der Praxis und viel- 
versprechende neue theoretische Ansätze - all dies sind typische HMD- 
Themen.“ 

• Information Management: Die Zeitschrift stellt „Konzepte, Methoden und 
Techniken für ein erfolgreiches Informationsmanagement vor mit Blick 
auf Technik, Organisation, Personal und Gonsulting. Hochkarätige Auto- 
ren aus Industrie, privater und öffentlicher Dienstleistung sowie aus dem 
Gonsulting-Bereich vermitteln Praktikern, Lehrenden und Lernenden im 
Informationsmanagement praxisorientierte und zugleich wissenschaftlich 
fundierte Impulse.“ 

• European Journal of Information Systems: „The European Journal of Infor- 
mation Systems provides a distinctive European perspective on the theory 
and practice of information Systems for a global audience. We encourage 
first rate research articles by academics, but also case studies and reflec- 
tive articles by practitioners. We provide a critical view on technology, 
development, Implementation, strategy, management and policy.“ 

• Information Systems Research (ISR) wird von der INFORMS herausgege- 
ben: „Information Systems Research is a leading international Journal of 
theory, research, and intellectual development, focused on information sys- 
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tems in organizations, institutions, the economy, and society. Information 
Systems Research is dedicated to furthering knowledge that aids in the 
productive application of information technology to human organizations 
and their management, and more broadly, to improved economic and social 
welfare. ISR’s interests are wide ranging, seeking contributions that build 
on established lines of work as well as break new ground. [. . .] The editorial 
policy of ISR is predicated on the belief that technologies and techniques 
for the Collection, storage, management and use of information of all kinds 
are a foundation of economic and social development, and their successful 
use and subsequent effects are a vital arena for rigorous research of all 
kinds. The ISR community is not constrained by disciplinary boundaries.“ 
• Management Information Systems Quarterly: „The topics of all articles 
in all departments of MIS Quarterly must relate to the journal’s editori- 
al objective, which is the development and communication of knowledge 
concerning both the management of information technology and the use of 
information technology for managerial and organizational purposes. Ma- 
nuscripts focusing on information technology generally need to examine 
a phenomenon in which the behavioral, the managerial, and/or the orga- 
nizational also play a substantive and not just incidental role. Similarly, 
manuscripts focusing on the behavioral, the managerial, and/or the orga- 
nizational generally need to examine a phenomenon in which information 
technology also plays a substantive and not just incidental role.“ 

Während die genannten Zeitschriften eher ihren wissenschaftlichen Cha- 
rakter in den Vordergrund stellen, gibt es eine Reihe populärwissenschaftli- 
cher Organe, denen sich unmittelbar Trends und Tendenzen entnehmen las- 
sen. Zu nennen sind hier z. B. die Wochenzeitungen Computer-Zeitung und 
Computerwoche. Darüber hinaus ist mittlerweile auch eine starke Diffundie- 
rung in nahezu beliebige andere Bereiche zu konstatieren, so dass man in 
diversen Fachzeitschriften ohne unmittelbaren Wirtschaftsinformatik-Bezug 
ebenfalls qualifizierte Beiträge zu diesem Gebiet findet. Als Bindeglied zwi- 
schen populärwissenschaftlichen Organen und wissenschaftlichen Zeitschrif- 
ten findet man eine Reihe von Organen, die überblicksartig immer wieder 
aktuelle Themen aufgreifen und auf hoch stehendem Niveau erläutern; als 
Beispiel sei hierzu Communications of the ACM genannt. 

Alle zwei Jahre findet in Deutschland eine zentrale Wirtschaftsinformatik- 
Tagung statt (1995 Frankfurt am Main, 1997 Berlin, 1999 Saarbrücken, 2001 
Augsburg, 2003 Dresden, 2005 Bamburg und 2007 Karlsruhe). Alternierend 
mit diesen Tagungen gibt es eine so genannte MKWI (Multikonferenz Wirt- 
schaftsinformatik; u. a. 2004 in Essen und 2006 in Passau). Die dazugehören- 
den Tagungsbände (z. B. König (1995), Krallmann (1997), Scheer und Nütt- 
gens (1999), Buhl et al. (2001), Uhr et al. (2003), Ferstl et al. (2005)) geben 
jeweils einen Überblick über den aktuellen Stand der Forschung. International 
sind die jährlich stattfindenden Konferenzen Hawaii International Conference 
on System Sciences (HICSS), International Conference on Information Sys- 
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tems (ICIS) und European Conference on Information Systems (ECIS) als 
bedeutende Wirtschaftsinformatik-Tagungen zu nennen. 

Etwas ernüchternd ist allerdings auch zu konstatieren, dass es im Bereich 
der Wirtschaftsinformatik eine „Unzahl“ an Tagungen mit entsprechenden 
Tagungsbänden sowie Publikationen mit stark überlappenden und bisweilen 
auch trivialen Inhalten gibt, so dass es sich oftmals als schwierig erweist, den 
Überblick zu behalten. 

WWW-Seiten zur Wirtschaftsinformatik im deutschsprachigen Raum 
finden sich unter http://www.isworld.org/isworldcountry/germany/ 
Index . htm. 



A.5 Berufsbilder 

„Sie suchen ein modernes Entwicklungsumfeld? Wir suchen Exper- 
ten und ambitionierte Quereinsteiger. IT - the way to the future.“ 
(Anzeige einer international tätigen Universalbank) 

Berufsbilder beschreiben das Aufgabenspektrum und mögliche typische 
Tätigkeiten eines Berufes bzw. einer Berufsgruppe. Für die Wirtschaftsinfor- 
matik lässt sich ein fest umrissenes Aufgabenspektrum zunächst nur schwer 
konkretisieren, da hierzu in der Praxis wie in der Theorie nach wie vor oft- 
mals die irrige Ansicht vorzufinden ist, dass alles, was mit Computern zu 
tun hat und in Verbindung mit wirtschaftswissenschaftlichen Funktionsbe- 
reichen steht, dem Tätigkeitsfeld der Wirtschaftsinformatik zuzurechnen ist. 
Das Berufsbild erstreckt sich dabei insbesondere auch auf den Wirtschafts- 
informatiker als „Sparringspartner“, der beide Seiten, die Informatik wie die 
Betriebswirtschaftslehre, versteht und deren Sprache spricht und als „Mittler 
zwischen den Welten“ fungieren kann. 

Darstellungen des Aufgabenspektrums der Wirtschaftsinformatik findet 
man z.B. in Mertens et al. (2002) oder bei der Bundesanstalt für Arbeit 
(1993); Hilfestellungen können aber auch die Stellenangebote überregiona- 
ler Tageszeitungen sowie einschlägiger Computerzeitungen geben. Folgende 
Aufgabenfelder lassen sich ableiten: 

• Forschung und Entwicklung zu Informations- und Kommunikationssyste- 
men 

• Entwurf, Entwicklung, Einführung und Wartung von (z. B. betrieblichen) 
Anwendungssystemen 

• Entwicklung und Einführung von Organisationskonzepten 

• Hard- und Softwarevertrieb 

• Anwenderunterstützung zu Anwendungssystemen 

• Potenzialerkennung und Implementierung neuer Methoden und Produkte 
im IT-Umfeld 

• Schulungsgestaltung und -durchführung 
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• Wahrnehmung von Führungsaufgaben im IT-Umfeld 

• Beratung im IT-Umfeld (Consulting) 

Aus übergeordneter Warte können sich Wirtschaftsinformatiker aufgrund 
der Vielfalt an Aufgabenfeldern sowohl als Generalisten als auch als Spezia- 
listen verstehen, je nachdem, welcher Ausrichtung sie sich verschreiben. Eine 
wesentliche Weichenstellung nimmt hierbei die Frage ein, inwiefern man eher 
als Anwender, als Berater oder als Entwickler tätig sein möchte. 

Unabhängig von den genannten Aufgabenfeldern hat es sich als charakte- 
ristisch erwiesen, dass Tätigkeiten im IT-Umfeld insbesondere in Projekten 
und kleinen Teams durchgeführt werden. Die Branche an sich unterliegt da- 
bei im Vergleich zu klassischen Industriebetrieben tendenziell weniger Ein- 
wirkungen von Gewerkschaften verbunden mit gegenüber Industriebetrieben 
erhöhter Arbeitszeitflexibilität. 

Seit Ende der 1990er Jahre stehen sehr vielen offenen Stellen für Wirt- 
schaftsinformatiker deutlich weniger qualifizierte Kandidaten zur Verfügung, 
als nachgefragt werden. Daraus resultierte in Deutschland neben einer Diffun- 
dierung von Mitarbeitern und Absolventen anderer Fachbereiche in die Wirt- 
schaftsinformatik auch eine grundsätzliche Veränderung des Arbeitsmarktes 
(begleitet von Schlagworten wie „Greencard“). 



A.6 Datenschutz 

Für die (Wirtschafts-)Informatik sind verschiedene rechtliche Gebiete von 
besonderer Relevanz. Dies bezieht sich etwa auf Urheber- und Patentrecht, 
rechtliche Regelungen im Zusammenhang mit der Anwendung von kryptogra- 
phischen Methoden sowie das im Folgenden näher betrachtete Datenschutz- 
recht. In diesen Bereichen wird die rechtliche Einschätzung von Tatbeständen 
häufig durch eine Internationalisierung verkompliziert. Ein entsprechendes 
Beispiel im Electronic-Gommerce-Bereich ist der Kauf eines Produktes eines 
Anbieters aus Land A durch einen Kunden in Land B über einen in Land G 
ansässigen Intermediären unter Verwendung des Internets, wobei die eigent- 
liche technische Abwicklung über einen WWW-Server in Land D erfolgt. 

Datenschutz^ verfolgt die Zielsetzung, Informationen über persönliche 
Lebenssachverhalte vor Missbrauch zu schützen.® Die Notwendigkeit für 
diesbezügliche Regelungen entstand vor allem durch die fortschreitenden 
Möglichkeiten der modernen Informations- und Kommunikationstechnik; ins- 
besondere durch die fortschreitende Vernetzung und Integration von Informa- 
tionssystemen ergeben sich neue Potenziale zur Informationserschließung und 
-nutzung. Durch das Bundesverfassungsgericht wurde in Deutschland (im so 

^ Vgl. etwa BfD (Der Bundesbeauftragte für den Datenschutz) (2003), Gola et al. 
(2005) sowie Tinnefeid et al. (2005). 

® In diesem Zusammenhang werden die Begriffe Daten und Informationen oft un- 
einheitlich bzw. synonym verwendet. 
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genannten Volkszählungsurteil von 1983) aus dem allgemeinen Persönlich- 
keitsrecht das Recht auf informationeile Selbstbestimmung abgeleitet: das 
Selbstbestimmungsrecht jedes Einzelnen, grundsätzlich über die Preisgabe 
und Nutzung seiner persönlichen Daten zu entscheiden. 

Es existieren verschiedene relevante Rechtsvorschriften, die den Daten- 
schutz regeln: Bundesdatenschutzgesetz, Datenschutzgesetze der Länder, be- 
reichsspezifische datenschutzrechtliche Regelungen in anderen Gesetzen und 
Verordnungen sowie die Datenschutzrichtlinie der Europäischen Union (EU). 
In diesem Zusammenhang ist das Problem der Internationalisierung anzu- 
sprechen. Dem relativ hohen Datenschutzniveau in Deutschland bzw. der EU 
stehen oft weniger restriktive Regelungen gegenüber, was bei der grenzüber- 
schreitenden Verarbeitung und Nutzung personenbezogener Daten zu gewis- 
sen Problemen führt. Im Weiteren werden die wesentlichen Grundregelungen 
des deutschen Bundesdatenschutzgesetzes (BDSG) von 1990 in Verbindung 
mit der EU-Datenschutzrichtlinie von 1995, die zu einer Anpassung bzw. 
Annäherung des nationalen Datenschutzrechtes der EU-Länder führt, zusam- 
mengefasst. 

Das Bundesdatenschutzgesetz gilt für alle öffentlichen Stellen des Bundes, 
teilweise in Verbindung mit dem jeweiligen Landesdatenschutzgesetz auch für 
öffentliche Stellen der Länder, sowie für nichtöffentliche Stellen, sofern dort 
personenbezogene Daten nicht ausschließlich zu privaten Zwecken verarbei- 
tet und genutzt werden. Bezüglich der Einbeziehung von nicht automatisiert 
verarbeiteten Daten in Vorgangsakten o. A. sind die verschiedenen Daten- 
schutzregelungen teilweise uneinheitlich. Geschützt sind jedoch in der Re- 
gel Daten in Dateien (strukturierte Sammlung personenbezogener Daten, die 
nach bestimmten Merkmalen verarbeitet werden können), unabhängig von 
einer automatisierten Verarbeitung, sowie auch personenbezogene Ton- und 
Bilddaten. 

Einschränkungen des Rechtes auf informationeile Selbstbestimmung sind 
nur aufgrund eines Gesetzes zulässig („Verbot mit Erlaubnisvorbehalt“), das 
gewisse Mindestanforderungen erfüllen muss (überwiegendes Allgemeininte- 
resse, Normenklarheit, Verhältnismäßigkeit), oder bedürfen der expliziten Zu- 
stimmung durch den Einzelnen. Dabei sind folgende wichtige Grundsätze 
beim Umgang mit personenbezogenen Daten zu nennen: Es dürfen nur wirk- 
lich notwendige Daten erhoben, verarbeitet und genutzt werden (Erforder- 
lichkeit); die Datenerhebung muss in der Regel offen und direkt beim Betrof- 
fenen erfolgen; diese Daten dürfen in der Regel nur für den Zweck verwandt 
werden, für den sie erhoben wurden (Zweckbindungsgrundsatz, Geheimhal- 
tungspflicht); bei der Verarbeitung personenbezogener Daten sind gewisse 
technische und organisatorische Maßnahmen zu treffen, insbesondere sind ei- 
ne angemessene Datenqualität und Datensicherheit durch eine Verarbeitung 
nach Treu und Glauben zu gewährleisten. Für die weitere Verarbeitung und 
Nutzung gibt es gewisse Regelungen; insbesondere für eine Übermittlung von 
Daten an dritte Stellen werden spezielle Anforderungen gestellt. Dies gilt um 
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SO mehr bei der Verarbeitung hochsensibler Daten (wie z. B. politische oder 
religiöse Anschauungen, medizinische Informationen). 

Betroffene Personen besitzen ein Auskunftsrecht bezüglich der sie betref- 
fenden Daten; gegebenenfalls muss die speichernde Stelle Daten berichtigen, 
sperren oder löschen. Im Datenschutzrecht sind verschiedene unabhängige 
Kontroll- und Beschwerdeinstanzen vorgesehen, gewisse Datenverarbeitun- 
gen sind solchen Stellen zu melden. In Deutschland existiert die Funktion der 
Datenschutzbeauftragten beim Bund und bei den Ländern sowie bei öffent- 
lichen und nichtöffentlichen Stellen ggf. die Funktion des behördlichen bzw. 
betrieblichen Datenschutzbeauftragten. Deren primäre Aufgabe ist die Über- 
wachung und Sicherstellung des Datenschutzes. 



A.7 Gesellschaftliche Auswirkungen 

„Die kontrollierenden Computer der Zukunft werden erzwingen, dass 

Arbeit Spaß macht. “ (Dueck (2002)) 

Die Untersuchungsobjekte der Wirtschaftsinformatik, d.h. Informations- 
und Kommunikationssysteme in Wirtschaft und Verwaltung, sind aus un- 
serem täglichen Leben nicht mehr wegzudenken. Nicht nur im beruflichen 
Umfeld, sondern nahezu in allen Lebensbereichen sind wir mit entsprechen- 
den Systemen und ihren Auswirkungen konfrontiert. Letztendlich kann man 
wahrscheinlich von einer annähernd vollständigen Durchdringung unseres Le- 
bens (zumindest in der „westlichen Welt“) mit Computern ausgehen; man 
spricht auch von „Pervasive (Uhiquitous) Computing“ sowie von „Pervasive 
Innovation“ . 

Sucht man Analogien zu dieser Entwicklung, so ist man zunächst versucht, 
sich im Bereich verschiedener industrieller Innovationsschübe umzuschauen, 
die oftmals auch als Kondratie ff- Zyklen bezeichnet werden; vgl. z. B. Nefio- 
dow (1991). Dabei handelt es sich um Konjunkturzyklen, die durch bahnbre- 
chende Innovationen bzw. entsprechende Innovationsschübe im Bereich des 
Aufbaues einer Infrastruktur hervorgetreten sind. Beispiele für solche circa 
ein halbes Jahrhundert umfassende Zyklen resultierten aus den Entwicklun- 
gen der Dampfmaschine oder des Automobiles. 

Ähnlich lassen sich Analogien im Aufbau von Verkehrsnetzen beobachten, 
wie sie z.B. in den Bereichen des Straßen-, des Schienen- oder des Luftver- 
kehrs zu konstatieren sind. Tabelle A.l skizziert den Aufbau verschiedener 
Verkehrsnetze sowie des Strom- und des Telefonnetzes. Vereinfacht kann man 
feststellen, dass sich auf verschiedenen Ebenen ähnliche Entwicklungen vollzo- 
gen haben. Auf der ersten Ebene steht zunächst ein Netz mit Vorgehensweisen 
und Regeln zu seiner Nutzung. Die zweite Ebene beschreibt Einrichtungen 
und Geräte zur Nutzung der ersten Ebene, und die dritte Ebene beinhaltet 
Unternehmen, die auf Basis dieser Einrichtungen Dienstleistungen anbieten. 
Die Dienstleistungen selbst sind auf der vierten Ebene beschrieben. 
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Straßen- 

verkehr 


Schienen- 

verkehr 


Luftverkehr 


Elektro- 

industrie 


Fernsprech- 

dienste 


Ebene 1 


Straßen, 

Straßenver- 

kehrsordnung 


Schienen 

und 

Signale 


Luftraum, 

Flughäfen, 

Flugkontrolle 


Stromnetz 


Telefonnetz 


Ebene 2 


Kraftfahr- 

zeuge 


Züge und 
Loks 


Flugzeuge, 

Luftschiffe 


Elektrische 
Maschinen 
und Geräte 


Telefon- und 
Faxgeräte 


Ebene 3 


Transport- 

unternehmen 


Bahn- 

gesell- 

schaften 


Luftverkehrs- 

gesellschaften 


Elektrizi- 

tätswerke 


Telekommu- 

nikationsge- 

sellschaften 


Ebene 4 


Personen- 
und Güter- 
transport 


Personen- 
und Güter- 
transport 


Personen- 
und Güter- 
transport 


Nutzer von 
elektrischen 
Geräten 


Ferngesprä- 
che, Doku- 
mentenüber- 
tragung 



Tabelle A.l. Beispiele für Versorgungsnetze und zugehörige Industriezweige; in 
Anlehnung an Bayer (1994) 



Vergleicht man die genannten Beispiele für Versorgungs- und Verkehrsnet- 
ze sowie die zugehörigen Industriezweige, so bestehen zunächst augenschein- 
liche Analogien zum Aufbau einer Informations- und Kommunikationsinfra- 
struktur wie dem Internet (z. B. eine grundlegende Anschubfinanzierung des 
Infrastrukturaufbaues durch staatliche Maßnahmen und Unterstützung ins- 
besondere in den USA; vgl. Abschnitt 2.5). Der so genannte Übergang zur 
Informationsgesellschaft mit unabhängig von Raum und Zeit verfügbaren In- 
formationen bedeutet ebenfalls die Hoffnung auf nachhaltiges Wachstum und 
Impulse für die Arbeitsmärkte usw. 

Im Gegensatz zu den bisherigen Kondratieff-Zyklen ist im Bereich der 
IKS eine deutlich höhere Innovationsgeschwindigkeit zu beobachten. Darüber 
hinaus erfolgt neben einer Ergänzung der bisherigen Netze eine nahezu 
vollständige Durchdringung bestehender Netze und Industriezweige, aber 
auch privater Lebensbereiche,® so dass die Frage nach den gesellschaftlichen 
Auswirkungen einer entsprechenden Veränderung insbesondere auch Wirt- 
schaftsinformatiker in ihrer Tätigkeit betrifft. Neue Formen des Informations- 
und Kommunikationsverhaltens unter Nutzung des elektronischen Datenaus- 
tausches sowie des Internets induzieren Fragen nach der Entwicklung, den 
Chancen und den Auswirkungen neuer Informations- und Kommunikations- 
technologie. Dies betrifft neben einer kritischen Auseinandersetzung mit Fra- 
gen der Technikfolgenabschätzung sowie der sinnhaften Vollautomation als 
möglichem Ziel der Wirtschaftsinformatik (vgl. die Einführung zu Kapitel 

® Deutlich wird dies, wenn man sich überlegt, welche Implikationen neue IT für die 
Planung, Steuerung und Kontrolle des Straßen-, Eisenbahn- sowie des Luftver- 
kehrs eröffnet. Vgl. auch die Infrastrukturveränderungen des täglichen Lebens 
unter den Schlagworten PC, Handy, SMS etc. 
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2) auch Maßnahmen im Bereich Bildung (einschließlich Weiterbildung), die 
sich nicht auf die bloße Einrichtung eines Lehrgebietes Wirts chaftsethik be- 
schränken dürfen. 

Dem Wirtschaftsinformatiker wie dem Informatiker obliegt hierbei eine 
wesentliche Verantwortung, Nutzern von IKS im Allgemeinen sowie spezifi- 
schen Anwendungssystemen ein geeignetes Zusammenspiel von Komplexität 
(im Sinne systembedingter Eigenschaften eines Systems) und Kompliziert- 
heit (im Sinne der Art der Modellierung und damit das induzierte Verstehen 
und Gestalten des Systems) zu gewährleisten; vgl. z.B. Biedenkopf (1994). 
Nur wenn eine ausreichende Fähigkeit zur Beherrschung der Komplexität 
vorhanden ist, kann eine gesellschaftliche Akzeptanz aktueller Entwicklun- 
gen der Informationstechnik erreicht werden. Anderenfalls kann eine latente 
Überforderung bei der Beherrschung der Komplexität durch zu komplizierte 
Zugangsmechanismen zu einer Ablehnung des gesamten Systems führen. 

Diskussionsbedarf ergibt sich aufgrund der Veränderung sozialer Struk- 
turen sowie gestiegener Lernanforderungen. Insbesondere im Falle von An- 
wendungssystemfehlern treten offensichtliche Probleme der Kontrollierbar- 
keit, der Überschaubarkeit sowie des möglichen Ausgeliefertseins gegenüber 
IKS auf. Offene Probleme sind darüber hinaus in verschiedenen Bereichen zu 
konstatieren (z. B. rechtliche Fragen im Zusammenhang mit dem Datenschutz 
oder mit Urheberabgaben für „digitale“ Produkte; vgl. Abschnitt A.6). 

Handlungsalternativen und ihre absehbaren Wirkungen fachübergreifend 
zu thematisieren, ist im Bereich der IKS sowie der damit einhergehenden Ver- 
netzung eine notwendige Aufgabe, mit der Einzelne zumeist überfordert sind. 
In diesem Zusammenhang obliegt es Gesellschaften wie der Gl, „die Zusam- 
menhänge zwischen individueller und kollektiver Verantwortung zu verdeutli- 
chen und dafür Verfahren zu entwickeln“ (http://www.gi-ev.de). Sinnvolle 
Werkzeuge, die neben der Verantwortung jedes Einzelnen durch derartige 
Gesellschaften übernommen werden können, sind die Mediation sowie die ge- 
meinschaftliche Reflexion von Problemen mit einem normativen Hintergrund, 
die vom Einzelnen bzw. auch der Wirtschaftsinformatik als Fachdisziplin ins- 
gesamt nicht überschaut werden können. Unter Mediation werden dabei Ver- 
handlungsprozesse verstanden, mit deren Hilfe Interessenkonflikte zwischen 
verschiedenen Parteien unter Hinzuziehung eines neutralen Dritten beigelegt 
werden. Dabei ist zwischen technischer Realisierbarkeit und gesellschaftlichen 
wie wirtschaftlichen Anforderungen geeignet abzuwägen. 

Ein versöhnlicher Abschluss mag mit einem Blick auf das Frontcover unse- 
res Buches dennoch erlaubt sein. Selbst wenn wir auf der Basis von Schlagwor- 
ten wie Internet, Supply Ghain Management, EDI und Electronic Gommerce 
unser Spielzeug in einem fernöstlichen Unternehmen vom heimischen Sessel 
aus selbst konfigurieren können, die Ware muss immer noch zu uns trans- 
portiert werden - und es ist doch schön, wenn wir im Idealfall per Tracking 
and Tracing mit einer WebGam auf ein Gontainerterminal blicken und durch 
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geschicktes Zoomen „unser Spielzeug“ entdecken, kurz bevor es tatsächlich 
bei uns zu Hause eintrifft ;-) 




B. Lösungen zu den Übungen und 
Kontrollfragen 



B.l Einführung (zu Abschnitt 1.4) 

1. Eine in der Praxis weit verbreitete Schwerpunktsetzung liegt auf den 
praktischen (Gestaltungs-)Aufgaben der Wirtschaftsinformatik, wie 
Konzeption, Entwurf, Entwicklung und Betrieb von (konkreten) Anwen- 
dungssystemen. Demgegenüber beschäftigt man sich in der Forschung 
und Wissenschaft insbesondere mit Aufgaben, bei denen nicht ein 
konkretes Anwendungssystem, sondern eher allgemeinere Strukturen im 
Vordergrund stehen. Hierzu gehören u. a. die Entwicklung von Modellen 
und Theorien zur Beschreibung und Erklärung von Anwendungssyste- 
men (z. B. Referenzmodelle) oder auch die (Weiter-)Entwicklung von 
Methoden und Werkzeugen, die die eigentliche Softwareentwicklung und 
-konzeption unterstützen können. 

2. Aus Sicht der Informatik wird die Wirtschaftsinformatik oftmals als Teil- 
disziplin der angewandten Informatik (neben Medizininformatik, Rechts- 
informatik u. A.) angesehen, da auch hier viele Methoden der Informa- 
tik (z. B. aus dem Software Engineering und dem Gebiet der Datenban- 
ken) genutzt werden und Software (in Form von Anwendungssystemen) 
im Mittelpunkt steht. Aus der Sicht der Betriebswirtschaftslehre kann 
Wirtschaftsinformatik eine Querschnittsfunktion innerhalb der Betriebs- 
wirtschaftslehre darstellen, die die Aufgabe hat, zur Unterstützung der 
wirtschaftlichen Nutzung des Produktionsfaktors Information (in allen 
Funktionsbereichen der Betriebswirtschaftslehre) geeignete IKS zu ent- 
wickeln (und zu betreiben). 

Eine Zuordnung zur Informatik oder auch Betriebswirtschaftslehre ist 
jedoch nicht sinnvoll, da in der Wirtschaftsinformatik Methoden und 
Techniken beider Disziplinen verwendet werden. Die Betrachtung der 
Wirtschaftsinformatik als Schnittstelle zwischen beiden Disziplinen greift 
jedoch auch zu kurz, da darüber hinaus auch zu anderen Fachrichtungen 
Beziehungen bestehen. So sind z. B. hinsichtlich der Akzeptanz der 
entwickelten Anwendungssysteme (und ihrer dementsprechenden Ge- 
staltung) Erkenntnisse der Psychologie oder der Arbeitswissenschaften 
zu beachten. Darüber hinaus werden in der Wirtschaftsinformatik 
eigenständige Theorien, Modelle sowie Werkzeuge entwickelt (z.B. 
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hinsichtlich der Architektur von Anwendungssystemen oder der Unter- 
nehmensmodellierung). Die Wirtschaftsinformatik ist somit mehr als 
nur die Schnittstelle zwischen Informatik und Betriebswirtschaftslehre. 

3. Unter Anwendungssystemen im engeren Sinne versteht man auf be- 
stimmte (abgegrenzte) Aufgabenbereiche bezogene Informationssysteme, 
wobei man hier in der Regel eine Beschränkung auf Software zu Grunde 
legt. Informations- und Kommunikationssysteme umfassen dagegen im 
Allgemeinen neben einem größeren Anwendungsbereich auch die ver- 
wendete Systeminfrastruktur sowie den Menschen und seine Interaktion. 

4. Bei der Anlieferung eines Containers per LKW sollten am Eingangs- 
tor des Containerterminals die Daten des Containers (Bestimmungsort, 
Schiff, Containertyp u. A.) aufgenommen und eine Anlieferungsbestäti- 
gung für den Fahrer erstellt werden. Hierfür wird ein Anwendungssys- 
tem zur Dateneingabe und Speicherung der Daten in einer Datenbank 
benötigt. Sinnvoll wäre auch ein Abgleich mit bereits vorhandenen Daten, 
z. B. für den Fall, dass die Containerdaten bereits vom Speditionsunter- 
nehmen per Datenfernübertragung an das Containerterminal übermittelt 
wurden und dadurch in der Datenbank bereits vorliegen. 

Ausgehend von diesen Daten kann dann eine Disposition des Stellplatzes 
stattfinden. Diese kann mittels eines Yardplanungssystems automatisiert 
werden, wenn für die Zuordnung von Containern auf freie Stellplätze 
geeignete Regeln implementiert werden. Hierzu werden neben den Con- 
tainerdaten (insbesondere zu Schiff und Containertyp) auch Daten zum 
Yard, vor allem zu den einzelnen Stellplätzen (belegt oder nicht, Be- 
legung von benachbarten Stellplätzen), benötigt. Auch für diese Daten 
ist eine Datenbank mit entsprechenden Abfragemöglichkeiten notwendig 
(z.B. für die Abfrage von benachbarten Stellplätzen). 

Der LKW muss nach der Aufnahme der Daten des angelieferten Con- 
tainers abgefertigt werden, d.h. der LKW muss entladen und der Con- 
tainer mittels eines geeigneten Fahrzeuges (z. B. einem Portalhubfahr- 
zeug) zu seinem Stellplatz transportiert werden. Hierfür muss eine Zu- 
ordnung der vorhandenen Portalhubfahrzeuge zu den abzufertigenden 
LKW/ Containern erfolgen. Auch diese Zuordnung kann durch ein An- 
wendungssystem automatisiert werden, wofür Daten zur aktuellen Po- 
sition und dem Zustand (frei/belegt) der Portalhubfahrzeuge sowie der 
spätere Stellplatz des Containers und der Entladeplatz des LKW benötigt 
werden. Gleichzeitig kann mit der Zuordnung auch eine Optimierung des 
Fahrweges des ausgewählten Portalhubfahrzeuges durchgeführt werden. 
Idealerweise findet diese Optimierung simultan mit der Zuordnung statt, 
so dass einem Container z.B. ein Fahrzeug mit möglichst kurzem Fahr- 
weg zum Container und anschließend zum Stellplatz zugeordnet wird; 
vgl. Steenken (1992). 
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Diese Zuordnung und die damit zusammenhängenden Daten (Contai- 
nernummer, Stellplatz, Entladeplatz des LKW sowie gegebenenfalls der 
optimale Fahrweg) müssen dem Fahrer des Portalhubfahrzeuges bekannt 
gegeben werden, was z. B. über Datenfunkgeräte in der Kabine der Fahr- 
zeuge erfolgen kann. Nach erfolgtem Abstellen des Containers kann der 
Fahrer den Stellplatz bestätigen, woraufhin z. B. eine Aktualisierung der 
Yarddatenbank erfolgen sollte. 

Dieses System kann auch für die Planung des Transportes der Contai- 
ner zu den Schiffen genutzt werden, da auch hier eine Zuordnung von 
Containern zu Portalhubfahrzeugen und deren Fahrwege bestimmt wer- 
den müssen. Für den Umschlag der Container auf die Schiffe werden 
Verladebrücken genutzt, für die die Reihenfolge des Verladens der Con- 
tainer vom bzw. auf das Schiff durch ein weiteres Anwendungssystem 
unterstützt werden kann. Zur Vertiefung dieser Problematik vgl. Steen- 
ken et al. (1993). 



B.2 Informatik und Informations- und 
Kommunikationstechnik (zu Abschnitt 2.7) 

B.2.1 Berechenbarkeit und Komplexität 

1. Man kann (unter gewissen Annahmen) nachweisen, dass kein Algo- 
rithmus eine Laufzeitkomplexität von kleiner als 0{n ■ logn) haben 
kann (Abschätzung nach unten). Da andererseits Algorithmen mit einer 
Laufzeitkomplexität von 0{n ■ log n) bekannt sind (Abschätzung nach 
oben), ist hiermit die exakte Laufzeitkomplexität des Sortierproblems 
definiert . 

2. Es sei X die gesuchte Geschwindigkeit des Computers und diese sei 
ausgedrückt in der benötigten Zeitdauer (Sekunden) für die Abarbeitung 
einer Elementaroperation. Da der Algorithmus 2" Elementaroperationen 
benötigt und n = 100 als Problemgröße gegeben ist, müssen 2^°° 
Elementaroperationen in 3600 Sekunden ausgeführt werden. Daraus 
ergibt sich: 2^°° • x = 3600, woraus folgt x = 2,8 • 10“^^. Ein derart 
schneller Rechner existiert jedoch nicht. (Geht man von einem Rechner 
mit einer gerade noch realistischen Geschwindigkeit von 10^*^ Elementar- 
operationen pro Sekunde aus, würde die Berechnungsdauer immer noch 
in der Größenordnung des Alters des Universums liegen.) 

3. Wäre das Aquivalenzproblem berechenbar, dann könnte man damit auch 
entscheiden, ob beide Programme für dieselben Eingabedaten terminieren 
(abbrechen) und könnte somit auch das Halteproblem entscheiden. Dieses 
ist jedoch erwiesenermaßen nicht berechenbar, womit folgt, dass auch das 
Aquivalenzproblem nicht berechenbar ist. 
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4. „Ich werde dieses Problem nicht im Allgemeinen mittels eines effizienten, 
exakten Algorithmus lösen können. Das liegt aber nicht an mir; seit 
Jahrzehnten bemühen sich viele kluge Köpfe vergeblich um die Lösung 
dieses Problems bzw. äquivalenter Probleme. Möglich erscheint mir 
lediglich die optimale Lösung kleiner Problemstellungen; ansonsten 
müssen wir uns wohl mit einer Näherungslösung begnügen.“ 

5. Auf Basis einfacher Schlussfolgerungen ergeben sich für die beiden 
angegebenen WHILE-Programme die folgenden Aussagen zur Laufzeit- 
komplexität: 

a) Die äußere Schleife wird n-mal durchlaufen. Die innere Schleife beim 
ersten Mal einmal, dann zweimal usw. bis zu n-mal im n-ten Durch- 
lauf der äußeren Schleife. Damit erhält man die folgende Anzahl aus- 
geführter Elementaroperationen: 

2 [r := 0; a := 0] 

-l-3n -I- 1 [äußere Schleife; jeweils 

„while o 7 ^ n do a := a -I- 1; b := 0;“ 
sowie der Abbruch] 

-|-3-(l-|-2-|-...-l-n) -l-n [innere Schleife; jeweils 

„while 6 7 ^ o do r := r -I- 1; b := b+ 1;“ 
sowie n Abbrüche] 

= 3 -I- 4n -I- 3 • n • (n -I- l)/2 
= l,5n2 -b 5,5n -b 3 
= 0{n'^) 

b) Für dieses Programm kann keine Laufzeitkomplexität bestimmt 
werden, da das Programm nicht terminiert (d.h. nie zum Ende 
kommt). Dies liegt daran, dass die innere Schleife erst beendet 
wird, wenn v den Wert 256 erreicht, der Wert von v aber vor der 
Schleife auf 0 gesetzt und innerhalb der Schleife nicht verändert 
wird. Demzufolge wird die Abbruchbedingung für die innere Schlei- 
fe nie erfüllt, so dass das Programm diese Schleife nie verlassen kann. 

6. Es sei n die Problemgröße auf dem langsamen Rechner, m die Problem- 
größe auf dem vierfach beschleunigten Rechner. Als feste Zeitspanne sei 
ein Wert T angenommen. Dann muss gelten: 

a) = T sowie = 4 • T und somit = 4 • n^. Daraus folgt 
m = 2 ■ n. Demzufolge wächst die Problemgröße multiplikativ um 2 
(verdoppelt sich also). 

b) 2” = T sowie 2™ = 4 • T, und somit 2™ = 4-2”. Daraus folgt 
log 2 2™ = log 2 4 -b log 2 2”, d. h. m = 2 -b n. Demzufolge wächst die 
Problemgröße nur additiv um 2. 




B.2 Informatik und Informations- und Kommunikationstechnik 



275 



7. Ja. Zum einen kann ein Compiler das Java-Programm in ein Maschinen- 
sprachenprogramm übersetzen. Zum anderen folgt die Antwort aus der 
Churchschen These. 

8. Nein. Die Prüfung der Ausgaben des Programms würde im Allgemeinen 
erfordern, zu entscheiden, ob das Programm für alle entsprechenden 
Eingaben anhält. Dies entspricht aber dem Halteproblem, das als nicht 
berechenbar nachgewiesen wurde. 

9. a) Ja. Wenn man aus allen möglichen Wegen den kürzesten Weg 

auswählt, dann ist das natürlich auch ein kürzester. 

b) Der vorgeschlagene Algorithmus hat zur Folge, dass bei n Knoten 
bis zu (n — 2)! verschiedene Wege zu bewerten sind, was einem 
exponentiellen Aufwand (0(2”)) entspricht. 

c) Aus den beiden vorhergehenden Antworten kann geschlossen werden, 
dass die Problemstellung zumindest mit exponentiellem Aufwand be- 
rechenbar ist. Nichtsdestotrotz ist es nach obigen Antworten nicht 
auszuschließen, dass ein effizienter Algorithmus existiert. 

B.2. 2 Bits &L Bytes 

1. a) COhex = 12 • 16^ -k 0 • 16° = 12 • 16 = 192 

b) lOllOOllduai = 128 -k 32 -k 16 -k 2 -k 1 = 179 

c) Im Folgenden sind zwei alternative Berechnungsmöglichkeiten 
angegeben: 

• 352okt = 3 • 82 -k 5 • 8^ -k 2 • 8° 

= Olldual • 82 + lOldual ' 8^ + OlOdual ' 8° 

= lllOlOlOdual 

• 352okt = 3 • 82 -k 5 • 8^ -k 2 • 8° = 3 • 64 -k 5 • 8 -k 2 = 234 
234 = 128 -k 64 -k 32 -k 8 -k 2 

= 1 • 2^ -k 1 • 2° -k 1 • 2° -k 0 • 2^ -k 1 • 2° -k 0 • 22 -k 1 • 2^ -k 0 • 2° 

= lllOlOlOdual 



2. 200 • 400 Punkte = 80000 Punkte 

Jeder Punkt kann eine von 256 = 2® Farben besitzen. 

=k Abspeicherung der Farbinformation je Punkt mittels 8 Bit. 
=k Insgesamt müssen 80000 • 8 Bit = 640000 Bit übertragen 
werden. 

=k Bildübertragung dauert 640000 Bit/64000 Bit/s = 10 s. 
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3. 1,5 MByte + 100 KByte = 1500 KByte + 100 KByte = 1600 KByte 
Die Übertragungsdauer x (in Sekunden) für Seite und Logos kann dann 
wie folgt berechnet werden: 

Datenmenge 1600 KByte 

2) ^ ^ ^ g 

Bandbreite 100 KByte/s 

Das heißt, es dauert (mindestens) 16 Sekunden, um die Seite mit den 
unveränderten Logos herunterzuladen. 

Sei y die maximale Größe (in KByte) der Logos, dann gilt: 

j/ + 100 KByte 
100 KByte/s 

Nach y aufgelöst ergibt sich dann: 

y = (4 s • 100 KByte/s) - 100 KByte = 400 KByte - 100 KByte 
= 300 KByte 

Die Differenz zwischen alter und neuer Größe beträgt dann 



1500 KByte - 300 KByte = 1200 KByte. 



Der Prozentsatz z, um den die Logos verkleinert werden müssen, ergibt 
sich somit folgendermaßen: 

z 1200 KByte 
100% ^ 1500 KByte 



Daraus ergibt sich: 



2 = 100 % • 



1200 KByte 
1500 KByte 



100% • 0,8 = 80% 



4. Im Folgenden sind zwei alternative Rechenwege angegeben: 

• 0,621E-1 • 0,41E2 = (0,621 • 0,41)E(-1 + 2) = 0,25461E1 

• 0,621E-1 • 0,41E2 = 0,0621 • 41 = 2,5461 = 0,25461E1 



B.2.3 World Wide Web 



1 . 



a) 



<!ELEMENT Bestellung (Kundendaten, (Artikel)+)> 
<! ELEMENT Kundendaten (Name, Nummer, Anschrift)> 
<! ELEMENT Name (\#PCDATA)> 

<! ELEMENT Nummer (\#PCDATA)> 

<!ELEMENT Anschrift (Strasse , PLZ, Ort)> 

<! ELEMENT Strasse (\#PCDATA)> 

<! ELEMENT PLZ (\#PCDATA)> 
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<!ATTLIST PLZ 

Land D|A \#REQUIRED 

> 

<! ELEMENT Ort (\#PCDATA)> 

<! ELEMENT Artikel (Name, Nummer, Preis, Menge) > 

<! ELEMENT Preis (\#PCDATA)> 

<! ELEMENT Menge (\#PCDATA)> 

b) <?xml version=" 1 . 0"?> 

<!D0CTYPE Bestellung SYSTEM "bestellung.dtd"> 
<?xml-stylesheet type="text/css" href="bestellung. css"> 
<Bestellung> 

<Kundendaten> 

<Name>Stefan Voß</Name> 

<Nummer>987654</Nummer> 

<Anschrift> 

<Strasse>Von-Melle-Park 5</Strasse> 

<PLZ Land="D">20146</PLZ> 

<0rt >Hamburg< /Ort > 

</Anschrift> 

< /Kundendat en> 

<Artikel> 

<Name>Grundlagen der Wirtschaf tsinformatik</Name> 
<Nummer >3-7908- 1375-3</Nummer> 

<Preis>19,94</Preis> 

<Menge>4</Menge> 

</Artikel> 

<Artikel> 

<Name>Inf ormationsmanagement</Name> 
<Nummer>3-540-67807-7</Nummer> 

<Preis>29,95</Preis> 

<Menge>K/Menge> 

</Artikel> 

</Bestellung> 



B.3 Informationsmanagement (zn Abschnitt 3.7) 

1. Die Begriffe „Daten“, „Information“ und „Wissen“ sollen hier am Beispiel 
der mathematischen Formel = c? erläutert werden. Sowohl die 

einzelnen Bestandteile dieser Formel (d. h. die Buchstaben a, b und c, 
die hochgestellte Zahl 2 sowie die Zeichen -|- und =) als auch die Formel 
selbst sind Daten. 

Erst durch eine Interpretation dieser Formel entsteht eine Information. 
Diese Interpretation beinhaltet zum einen die Feststellung, dass diese 
Zeichen eine Formel darstellen und die Buchstaben o, b und c Wer- 
te repräsentieren. Zum anderen kann durch das Herstellen von Zusam- 
menhängen zu anderen Daten und Informationen (z. B. einer Abbildung 
eines rechtwinkligen Dreieckes) möglicherweise erkannt werden, dass c die 
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längste, a und b dagegen die beiden kürzeren Seiten eines derartigen Drei- 
eckes bezeichnen. Somit ergibt sich für die Formel die Bedeutung, dass in 
einem rechtwinkligen Dreieck das Quadrat der Länge der längsten Seite 
gleich der Summe der Quadrate der Längen der anderen beiden Seiten 
ist. 

Hieraus kann man eine Vorschrift (Regel) für die Berechnung der Länge 
einer Seite eines rechtwinkligen Dreieckes aus den beiden anderen 
Seiten ableiten. Allerdings wird dafür weiteres Wissen benötigt, z.B. 
Wissen darüber, wie man eine derartige Formel so umstellt, dass eine 
Berechnungsvorschrift entsteht. Diese Vorschrift stellt Wissen (Kenntnis 
von Sachverhalten) dar, das durch die Verarbeitung von Informationen 
über die Bedeutung der Formel gewonnen wurde. 

2. Wirtschaftsinformatik befasst sich mit der Konzeption, Entwicklung, 
Einführung, Wartung und Nutzung von Systemen der computergestütz- 
ten Informationsverarbeitung im Betrieb. Informationsmanagement kann 
man als wirtschaftliche (effiziente) Planung, Beschaffung, Verarbeitung, 
Distribution und Allokation von Informationen als Ressource zur Vorbe- 
reitung und Unterstützung von Entscheidungen (Entscheidungsprozes- 
sen) definieren. 

Innerhalb des Informationsmanagements gibt es einige Aufgaben, die 
nicht zur Wirtschaftsinformatik hinzugerechnet werden können. Hierzu 
zählt insbesondere die Analyse des Informationsbedarfe und -angebote, 
die keine originäre Aufgabe der Wirtschaftsinformatik (wohl aber des In- 
formationsmanagements) darstellt. Darüber hinaus beschäftigt sich das 
Informationsmanagement auch mit der Planung, Beschaffung, Verarbei- 
tung, Distribution und Allokation von Informationen, die nicht in elekt- 
ronischer Form vorliegen. Daneben umfasst auch die Wirtschaftsinforma- 
tik Aufgaben, die nicht essenziell zum Informationsmanagement gehören, 
insbesondere die Entwicklung und Anpassung von Software. Das Infor- 
mationsmanagement ist eher für die Steuerung dieser Tätigkeiten als für 
ihre Durchführung zuständig. 

Da zu beiden Gebieten (zumindest nach den oben angegebenen Defi- 
nitionen) zum Teil unterschiedliche Aufgaben gehören, haben sowohl 
die Wirtschaftsinformatik als auch das Informationsmanagement eine 
eigenständige Daseinsberechtigung. 

3. • Analyse und Ermittlung des Informationsbedarfes (Ebene des In- 

formationseinsatzes): Welche Informationen sind zur Lösung einer 
Aufgabe (bzw. für eine Entscheidung) notwendig? Bei komplexen 
Aufgaben ist der (objektive) Informationsbedarf nur selten aus der 
Aufgabe direkt ableitbar, daher werden auch subjektiver Verfahren 
(z.B. Befragungen) verwendet. 
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• Informationsbeschaffung (Ebene des Informationseinsatzes): Vor einer 
Bereitstellung von Informationen an Entscheidungsträger müssen diese 
beschafft werden. I. Schritt: Quellensuche (Wo liegen die gesuchten In- 
formationen? Welche Kosten entstehen für die Beschaffung aus dieser 
Quelle?), 2. Schritt: Auswahl der Quelle, aus der die Information be- 
schafft wird, und anschließend die eigentliche Beschaffung (Transport). 

• Informationsbereitstellung (Ebene des Informationseinsatzes): Hierbei 
werden die Informationen den Bedarfsträgern zur Verfügung gestellt 
(z. B. mittels IKS). Es entsteht das Problem, die richtige Information 
zum richtigen Zeitpunkt am richtigen Ort (Empfänger) zu den 
richtigen Kosten bereitzustellen. Daraus ergeben sich zwei Aufgaben: 
die Allokation (Zuordnung der Informationen zu Bedarfsträgern, d.h. 
wer bekommt welche Informationen?) und die Distribution (Auswahl 
von Medium und Weg für den Transport der Informationen zu den 
Empfängern) . 

• Datenmanagement (Ebene der Informations- und Kommunikations- 
systeme): Hierzu gehört die Planung, Steuerung und Überwachung 
der gesamten Daten des Unternehmens. Dies beinhaltet u. a. folgende 
Aufgaben: unternehmensweite Datenmodellierung, Organisation der 
Datenhaltung (Welche Daten werden in welchen Systemen verwaltet?), 
Regelung der Verantwortlichkeiten für Aktualität, Sicherheit usw. 
sowie Administration der Datennutzung (z. B. Zugriffsrechte). 

• Sicherheits- und Katastrophenmanagement (Ebene der Informations- 
und Kommunikationsinfrastruktur): Hierunter versteht man das 
Abwenden oder Vermindern realer (wirtschaftlicher) Schäden im 
Bereich der Informations- und Kommunikationssysteme (vor allem 
Gewährleistung von Datensicherheit und Datenschutz) sowie Planung 
von Schadensfällen, die extrem selten eintreten, jedoch sehr negative 
Folgen haben bzw. sehr große Schäden verursachen können. 

4. IM als persönliches Informationsmanagement befasst sich im Wesentli- 
chen mit den von einem Individuum für seine Informationsverarbeitungs- 
prozesse eingesetzten Methoden und Techniken, die ihm eine Bewälti- 
gung seiner (insbesondere betrieblichen) Aufgaben ermöglichen, d. h. dem 
persönlichen Umgang mit Information. Dem Ansatz kann die Überlegung 
zu Grunde liegen, dass sich aus einer „optimalen“ Informationsversor- 
gung jedes Mitarbeiters auch eine optimale Informationsversorgung des 
Unternehmens bzw. einer Organisation ergibt. Vermöge des persönlichen 
Informationsmanagements sollen die Mitarbeiter hinsichtlich des Erken- 
nens der eigenen Informationsbedarfe sowie der Mittel zu ihrer Befriedi- 
gung unterstützt werden; vgl. Seibt (1993). 

Das persönliche Informationsmanagement kann durch eine Vielzahl von 
Anwendungssystemen unterstützt werden, z.B. Standard-Office-Pakete, 
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Projektmanagementsoftware, Groupware-Applikationen, aber auch ein- 
fache Terminverwaltungssysteme. Auf der technischen Seite kann somit 
auch eine Unterstützung durch Organizer, Mobiltelefone u. A. erfolgen. 
So könnte man sich einen persönlichen Fahrplan (mit allen möglichen Ver- 
bindungen zwischen zwei Orten, z. B. Wohnung und Arbeitsplatz) u. a. 
mit einem WAP-fähigen Mobiltelefon über ein entsprechendes Angebot 
eines Verkehrsunternehmens erstellen. Voraussetzung für eine effiziente 
Unterstützung des persönlichen Umganges mit Informationen ist eine ge- 
eignete (gut ausgebaute) Netzinfrastruktur. 



B.4 Modellierung (zu Abschnitt 4.8) 

B.4.1 Unternehmensmodellierung 

1. Einerseits setzt die Überprüfung auf syntaktische Richtigkeit eines Mo- 
dells ein entsprechendes Meta-Modell voraus; im Hinblick auf die Ver- 
gleichbarkeit verschiedener Modelle ist entweder die Verwendung des glei- 
chen Meta-Modells oder eine Transformierbarkeit zwischen verschiede- 
nen Meta-Modellen erforderlich. Andererseits sind die Grundsätze ord- 
nungsmäßiger Modellierung auch bei der Erstellung von Meta-Modellen 
zugrunde zu legen. 



B.4. 2 Entity- Relationship- Modellierung 



1 . 
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2 . 




3. 
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4. 




B.4.3 Prozessmodellierung 

1. Die folgende Lösung verwendet bewusst keine adjunktiven Konnektoren, 
was teilweise zu einer Duplizierung von Modellbestandteilen führt. 
Mögliche alternative Lösungswege wären a) die Einführung einer Funk- 
tion, die entscheidet, was geprüft werden muss, mit einer nachfolgenden 
disjunktiven Verzweigung und einer spätereren korrespondierenden 
disjunktiven Zusammenführung, sowie b) die Einführung einer UND- 
Zusammenführung bei der Akzeptanz unter entsprechender Gestaltung 
des Vorlaufs. 
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Auftrag eh 



eingegangen 



X 



Konsistenz- und VoUständigkeitsprüfimg 



<C^^ ^Auftrag konsistent^ und vollständig'^ ^^^^ 
f Angefragte Vertragsart feststellen J 

I — ^ 

mit Münatsgehühr ^ 





T 

-<v)- 



1 



KW-Prüfung 



X 



1 



Vertrags-Prüfung 



I 



<( ^KW-Pr. erfolgt^ Vertr.-Pr. erfol^^ 



Feststellen, ob beide 
Prüfiingen erfolgreich 



X 



X 



{ negativ ^ beide i. O. ^ 



Auftrag hat 
formale Mängel 



X 



<T Prepaid y 
Vertrags-Prüfung 

(X 



kein bestehen- 
der Vertrag 



bestehender 

Vertrag 



Akzeptanz per 
E-Mail mitteilen 



Ablehnung per 
E-Mail mitteilen 



Vertrag akzeptiert ^ 



Vertrag abgelehnt ^ 



2 . 



Objektreservoir 



Schlange Gericht 1 
k=10 



Eingangs- 
tür 




o 



Gericht 1 



Bedienstete! 



k=15 Kasse k=150 Ausgang 

I>XHC>X 



O 



k=10 

Schlange Gericht 2 



Ö 



Obj ektreservoir 
Gericht 2 



3. In der dargestellten Lösung folgen wir den von van der Aalst (1999) 
beschriebenen Transformationsregeln (andere Lösungen sind möglich). 
Hierbei werden prinzipiell Ereignisse durch Stellen sowie Funktio- 
nen durch Transitionen eines Bedingungs-Ereignis-Netzes abgebildet. 
Konnektoren sind in Abhängigkeit von dem Zusammenhang durch 
verschiedene Teilstrukturen zu ersetzen, die (unter Ausnahme adjunk- 
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tiver Konnektoren) leicht nachvollzogen bzw. selbst entwickelt werden 
können. 



Ereignis 1 ( ) Ereignis la 



Funktion 1 



Ereignis 4 



Ereignis 2 




Ereignis Ib 



Ereignis 3 



B.4.4 Simulation 

1. Modellierung: 

• unbewegliche Objekte: 

— Eingang für Rollstuhlfahrer R 

— 19 andere Eingänge EOl, . . E19 

— 20 Warteschlangen WR, WEOl, . . WE19 

• bewegliche Objekte: Zuschauer 

• Zustände: 

— Eingänge: frei/belegt 
— Warteschlangen: frei/belegt (Länge) 

— Zuschauer: wartend/in Bedienung 

• Entscheidungsregeln: 

— Rollstuhlfahrer benutzen den Eingang R bzw. die Warteschlange WR 
— Alle anderen Zuschauer entscheiden folgendermaßen: 

i. Sind mehrere Eingänge frei, dann gehe zu dem freien Eingang 
Ea: mit der kleinsten Nummer. 

ii. Ist genau ein Eingang frei, dann gehe zu diesem. 

iii. Sind alle Eingänge belegt, dann gehe zur kürzesten Warte- 
schlange. 

Umsetzung des Modells in ein Simulationsmodell: Hierfür werden vorge- 
fertigte Bausteine verwendet. Die Entscheidungsregeln müssen in einer 
Simulationssprache programmiert werden. Außerdem müssen die Ein- 
gangsdaten (hier Eintreffzeitpunkte) stochastisch erzeugt oder durch Ta- 
bellen eingelesen werden. 

Simulationsexperimente: Diese können bei kleinen Modellen manuell er- 
folgen, werden in der Regel aber per Rechner zumeist unter Verwendung 
von Simulationssystemen (mit graphischer Modellierungsoberfläche und 
Visualisierung) durchgeführt. Wichtige Ergebnisgrößen sind in diesem 
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Beispiel die Zuschauerwartezeiten und Warteschlangenlängen (jeweils 
maximal/minimal/Durchschnitt) sowie die Auslastung der Eingänge. 
Übertragung der Ergebnisse auf die Realität: Es muss überprüft werden, 
ob alle Prämissen und Eingabedaten hinreichend realistisch waren und 
gegebenenfalls weitere Simulationen erforderlich sind. Eine anschließende 
Veränderung der realen Situation entsprechend der Simulationsauswer- 
tung sollte Kosten-Nutzen-Gesichtspunkte berücksichtigen. 

a) Ausgehend von den vorgegebenen Zuordnungsregeln ergibt sich 
folgender Ereigniskalender: 



Zeitpunkt 


Aktion 


Warteschlange G 


Warteschlange Z 


1 


Eintritt Gl 


Gl 




3 


Eintritt G2 


Gl, G2 




7 


Eintritt ZI 


Gl, G2 


ZI 


7 


Zuordnung G2 - ZI 


Gl 




8 


Eintritt Z2 


Gl 


Z2 


8 


Zuordnung Gl - Z2 






19 


Eintritt G3 


G3 




20 


Eintritt Z3 


G3 


Z3 


20 


Zuordnung G3 - Z3 






23 


Eintritt G4 


G4 




29 


Eintritt Z4 


G4 


Z4 



b) Nein, Gast G4 kann nicht zugeordnet werden, da G4 nur zu Zimmer 
Z3 passt, dieses Zimmer jedoch beim Eintreffen von G4 schon an 
jemand anderen (nämlich G3) vergeben wurde. 

c) Eine Möglichkeit wäre, die erste Regel zu verändern: 

Die Zuordnung von Gästen zu Zimmern erfolgt erst, wenn alle 
Zimmerwünsche bzw. Zimmerangebote eingegangen sind, d. h. 
spätestens zwei Monate vor Beginn der Großveranstaltung. Solange 
werden neu eintreffende Gäste/Zimmer in die Warteschlangen 
eingereiht. 

d) Denkbar wären die folgenden geänderten Regeln: 

i. Die Zuordnung von Gästen zu Zimmern erfolgt erst, wenn al- 
le Zimmerwünsche bzw. Zimmerangebote eingegangen sind, d. h. 
spätestens zwei Monate vor Beginn der Großveranstaltung. So- 
lange werden neu eintreffende Gäste/Zimmer in die Warteschlan- 
gen eingereiht. 

ii. Steht für einen Gast nur ein geeignetes Zimmer zur Verfügung 
bzw. existiert für ein Zimmer nur ein geeigneter Gast, so ord- 
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ne diesen Gast diesem Zimmer zu und streiche beide aus ihren 
Warteschlangen . 

iii. Wiederhole die Regel ii, bis für jeden Gast in der Warteschlange 
mindestens zwei geeignete Zimmer und für jedes Zimmer in der 
Warteschlange mindestens zwei geeignete Gäste zur Verfügung 
stehen. 

iv. Ordne jetzt die verbleibenden Gäste/Zimmer so zu, dass dem am 
längsten wartenden Gast oder Zimmer der Vorrang gegeben wird. 

e) Diese veränderten Regeln führen zum nachfolgenden Ereigniskalen- 
der, aus dem ersichtlich ist, dass nun alle Gäste ein Zimmer erhalten. 



Zeitpunkt 


Aktion 


Warteschlange G 


Warteschlange Z 


1 


Eintritt Gl 


Gl 




3 


Eintritt G2 


Gl, G2 




7 


Eintritt ZI 


Gl, G2 


ZI 


8 


Eintritt Z2 


Gl, G2 


ZI, Z2 


19 


Eintritt G3 


Gl, G2, G3 


ZI, Z2 


20 


Eintritt Z3 


Gl, G2, G3 


ZI, Z2, Z3 


23 


Eintritt G4 


Gl, G2, G3, G4 


ZI, Z2, Z3 


29 


Eintritt Z4 


Gl, G2, G3, G4 


ZI, Z2, Z3, Z4 


29 


Zuordnung G4 - Z3 


Gl, G2, G3 


ZI, Z2, Z4 


29 


Zuordnung G3 - ZI 


Gl, G2 


Z2, Z4 


29 


Zuordnung G2 - Z2 


Gl 


Z4 


29 


Zuordnung Gl - Z4 







3. a) Eine Einordnung aller Ereignisse anhand der vorgegebenen Regeln 
führt zu folgendem Diagramm: 




Aus der Simulation ergibt sich somit nachfolgender Ereigniskalender: 
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Zeit 


Ereignis 


WM 


WW 


0 


Ankunft ml, Zugang WW 


- 


ml 


10 


Ankunft m2, Zugang WM 


m2 


ml 


20 


Weggang m2, Abgang WM 


- 


ml 


25 


Ankunft w3, Zugang WM 


w3 


ml 


30 


Weggang ml, Abgang WW 


w3 


- 


35 


Ankunft w4, Zugang WW 


w3 


w4 


40 


Ankunft m5, Zugang WW 


w3 


w4, m5 


45 


Weggang w4, Abgang WW 


w3 


m5 


50 


Ankunft w6, Zugang WM 


w3, w6 


m5 


55 


Ankunft w7, Zugang WW 


w3, w6 


m5, w7 


75 


Weggang w3, Abgang WM 


w6 


m5, w7 


95 


Weggang w6, Abgang WM 


- 


m5, w7 


105 


Weggang m5, Abgang WW 


- 


w7 


110 


Weggang m7, Abgang WW 


- 


- 



b) Nein, Mitarbeiter M schafft es nicht, um 12:30 Uhr in der Mensa zu 
sein, da er insgesamt 95 Minuten für die Sprechstunde braucht (11:00 
Uhr plus 95 Minuten ergibt 12:35 Uhr). 

B.4. 5 Mathematische Modellierung 

1. Zuerst sollte man sich über die Parameter dieses Problems im Klaren 
werden. Hierzu gehören die Anzahl der Kommunikationsmittel n (in un- 
serem Beispiel 3) und die Anzahl der zu versendenden Nachrichten m. 
Außerdem müssen die Kosten beachtet werden, d. h. es gibt Fixkosten 
für jedes Kommunikationsmittel i und variable Kosten Cij für jede Nach- 
richt j unter Verwendung von Kommunikationsmittel i. Wenn für eine 
Nachricht j ein Kommunikationsmittel i nicht verwendet werden kann, 
kann dies u. a. durch sehr hohe Kosten (z. B. = 1.000.000 DM) 
abgebildet werden. Da die (variablen und fixen) Kosten nur dann auftre- 
ten, wenn eine Nachricht j mit dem Kommunikationsmittel i verschickt 
wird bzw. wenn das Kommunikationsmittel i überhaupt angeschafft wird, 
müssen die Variablen diese Entscheidungen widerspiegeln. Demzufolge 
führen wir eine Variable yi ein, die angibt, ob das Kommunikationsmittel 
i angeschafft werden soll (y^ = 1) oder nicht (j/j = 0). Außerdem werden 
Variablen Xij benötigt, die jeweils angeben, ob eine Nachricht j mit dem 
Kommunikationsmittel i verschickt wird {xij = 1) oder nicht {xij = 0). 
Die Zielfunktion F(x,y) ergibt sich dann als Summe aller Produkte der 
Kosten mit den entsprechenden Variablen. Mit den Nebenbedingungen 
muss erstens sichergestellt werden, dass jede Nachricht mit genau einem 
Kommunikationsmittel versendet wird (Nebenbedingung B.l). Zweitens 
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muss jedes Kommunikationsmittel angeschafft werden, dass für (mindes- 
tens) eine Nachrichtenversendung verwendet wird (Nebenbedingung B.2). 
Ein (allgemeines) mathematisches Modell für dieses Problem lautet dann: 



Minimiere 



F{x,y) 



E 



fi ' Di + 







unter den Nebenbedingungen 



E/ ~ 1 

i=l 

m 

Xij <m-yi 
i=i 

Xij e { 0 , 1 } 

y^ G {0, 1} 



für j = 1, 2, . . . , TO 
für i = 1, 2, . . . , n 

für i = 1, 2, . . . , n und j = 1,2, ... ,m 
für i = 1,2,. . . ,n. 



(B.l) 

(B.2) 



2. a) Das Datenblatt enthält sinnvollerweise: 

• einen Bereich von n = 6 Zellen für die Entscheidungsvariablen 

Xi , . . . , Xq, 

• einen Bereich von n ■ T = 36 Zellen mit den Nettoauszahlungen 
ai,i) • ■ • ) ß6,6) 

• einen Bereich von n = 6 Zellen mit den Kapitalwerten ei, . . . , ee, 

• einen Bereich von T = 6 Zellen mit den Budgets bi, ... ,bß, 

• einen Bereich von n ■ T = 56 Zellen mit den tatsächlichen Netto- 
auszahlungen (in Abhängigkeit von den Entscheidungsvariablen), 

• einen Bereich von n = 6 Zellen mit den tatsächlich erreichten Ka- 
pitalwerten (in Abhängigkeit von den Entscheidungsvariablen), 

• einen Bereich von T = 6 Zellen mit den (für jede Periode geson- 
dert) aufsummierten tatsächlichen Nettoauszahlungen (zum Ab- 
gleich mit den Budgets) sowie 

• eine Zelle mit dem Zielfunktionswert (Summe der tatsächlich er- 
reichten Kapitalwerte) . 

Bei Verwendung eines Optimierungstools innerhalb der Tabellen- 
kalkulation sind in diesem die Zelle mit dem Zielfunktionswert, die 
Zellen mit den Variablen sowie die Nebenbedingungen anzugeben. 
Diese Nebenbedingungen betreffen zum einen die Budgetrestriktio- 
nen für alle Perioden und zum anderen die Einschränkung auf binäre 
Variablen. Außerdem müssen Sie angeben, dass die Zielfunktion 
maximiert werden soll. Als optimales Ergebnis sollte Ihnen dann 
vom Optimierungstool ausgegeben werden, dass die Investitionen 
2, 3, 5 sowie 6 getätigt werden, wodurch sich als Summe der 
Kapitalwerte 8000 Sesterzen ergibt. 
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b) Ein mögliches AMPL-Modell sieht wie folgt aus und spiegelt damit 
das mathematische Modell auf S. 143 wider: 

pararni n; 
parami T ; 
set NN := 1 . .n; 
set TT := 1 . .T; 
pararni e { NN } ; 
parami a { NN, TT }; 
param b { TT } ; 
var X { NN } binary; 

maximize 

F(x) : sum { i in NN } ( e [i] * x[i] ); 

subject to 

Budgetrestriktion { t in TT } : 

sum { i in NN } a[i,t] * x[i] <= b [t] ; 



B.5 Datenbanken (zn Abschnitt 5.7) 

1. Für die Sicherstellung eines konsistenten Zustandes der Datenbasis muss 
ein Datenbankmanagementsystem die Atomarität, Konsistenz, Isolation 
und Persistenz aller Transaktionen gewährleisten. Diese Eigenschaften 
werden unter dem Begriff ACID-Prinzip zusammengefasst; vgl. Ab- 
schnitt 5.2 dieses Buches. 

2. • Interne Ebene: 

— Datenstrukturen zur Abspeicherung der Daten auf physischen Spei- 
chermedien 

— Datenadministration 

• Konzeptionelle Ebene: 

— Logische Gesamtsicht der Daten 
— Datendeßnition und -manipulation 

• Externe Ebene: 

— Individuelle Sichten (Schemata) für Anwender bzw. Anwendungen 
— Jeder Benutzer erhält einen spezifischen (für ihn relevanten) Aus- 
schnitt des konzeptionellen Datenmodells. 

— Datendefinition, -manipulation und -abfrage 

3. a) FAHRER ( Name , . . .) 

KUNDE ( Tel-Nr . Name, Adresse, . . .) 

BESTELLUNG ( Bestell-Nr , Tel-Nr, Name, . . .) 

PIZZA (Nr, . . .) 

ZUTAT (Bezeichnung, . . .) 

BEINHALTET (Bestell-Nr, Nr, Anzahl, . . .) 
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BESITZT (Nr, Bezeichnung, . . .) 

b) SELECT BESTELLUNG.Name, KUNDE.Name, KUNDE.Adresse 
FROM KUNDE, BESTELLUNG 
WHERE BESTELLUNG.Bestell-Nr = ” 13” 

AND BESTELLUNG. Tel-Nr = KUNDE.Tel-Nr; 

4. a) GOMPUTER-SYSTEM ( Exemplar-Nr , Typ-Nr, Uni-Name, . . .) 

GS-TYP (Typ-Nr, Prozessor, Monitor, . . .) 

UNIVERSITAET ( Uni-Name , Stud- Anzahl, . . .) 

STUDENT ( Kreditkarten-Nr . Name, Tel-Nr, Uni-Name, . . .) 
AUSLEIHE (Exemplar-Nr, Kreditkarten-Nr, bis-wann, . . .) 
VORBESTELLUNG (Typ-Nr, Kreditkarten-Nr, wann, . . .) 

b) SELECT Tel-Nr 

FROM STUDENT, AUSLEIHE, GOMPUTER-SYSTEM 
WHERE AUSLEIHE. Exemplar-Nr 

= GOMPUTER-SYSTEM.Exemplar-Nr 
AND Typ-Nr = ”271” 

AND AUSLEIHE. Kreditkarten-Nr 

= STUDENT.Kreditkarten-Nr; 

5. a) PRODUKT ( P-Nr , Bezeichnung, . . .) 

ARBEITSGANG ( AG-Nr , Bezeichnung, BearbZeit, P-Nr, S-Nr, 

...) 

STATION f S-Nr , . . .) 

MASGHINE ( Inv-Nr , M-Name, S-Nr, . . .) 

M-TYP ( M-Name , Hersteller, . . .) 

BENÖTIGT (AG-Nr, M-Name, . . .) 

VORRANG (AG-Nr_vor, AG-Nr_nach, . . .) 

b) SELECT Hersteller 

FROM M-TYP, MASGHINE 
WHERE S-Nr = ”6” 

AND MASGHINE.M-Name = M-TYP.M-Name; 



B.6 Softwareentwicklung (zu Abschnitt 6.5) 

1. Ein verbreitetes Problem konventioneller Verfahren der Softwareent- 
wicklung ist die Verwendung verschiedener, teilweise inkompatibler 
Modellierungsmethoden in den einzelnen Aktivitäten, was zu ent- 
sprechenden Brüchen beim Übergang führt. Die objektorientierte 
Softwareentwicklung strebt dagegen eine durchgängige Behandlung von 
Analyse, Entwurf und Implementierung auf Basis eines einheitlichen 
Abstraktionsmechanismus und Methodengerüstes an. 
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2. Wesentliche Aufgaben des Projektmanagements sind: 

• Definition klarer, erreichbarer und akzeptierter Ziele und Zwischenziele 
als Basis aller Aktivitäten 

• Aufbau einer zeitlich befristeten Projektorganisation mit personifizier- 
ten Verantwortungen (Aufbauorganisation) 

• Bestimmung des technisch und wirtschaftlich geeigneten Projektablau- 
fes (Ablauforganisation) 

• Planung von realistischen und abgestimmten Leistungen, Terminen, 
Kapazitäten und Kosten (Projektplanung) 

• Motivation, Anleitung und Koordination aller betroffenen Mitarbeiter 
(Führung) 

• Laufende Überwachung und sofortige Steuerung bei Abweichungen 
für alle Randbedingungen, Ziele und Ergebnisse (Projektcontrolling) 

3. a) i. Anlegen einer neuen Sprintwertung: 

Funktionstyp: Dateneingabe 

Komplexität: komplex, da Datenbankzugriff wegen der Ein- 

gabeprüfung nötig ist. 

ii. Eingabe der drei Erstplatzierten einer Sprintwertung: 
Funktionstyp: Dateneingabe 

Komplexität: mittel, da 6 Datenelemente (Namen und Num- 

mern) einzugeben sind. 

iii. Eingabe der erhaltenen Punkte aus einer Sprintwertung bei 
den drei Erstplatzierten: 

Funktionstyp: Dateneingabe 

Komplexität: einfach, da nur die Punkte einzugeben sind. 

iv. Druckausgabe (in Listenform) der Sprintpunkte aller Fahrer: 
Funktionstyp: Datenausgabe 

Komplexität: einfach, da 4 Listenspalten (Name, Nummer, 

Team, Punkte) nötig sind. 

V. Abfrage nach dem Fahrer mit den meisten Sprintpunkten: 
Funktionstyp: Datenabfrage 

Komplexität: einfach, da nur 1 Schlüssel verwendet wird. 

b) Als Summe der Schwierigkeitsgrade ergibt sich S1 = 6 -1-4 -1-3-1- 4-1-3 = 
20. Daraus folgt dann BFP = S1 • 1,1 = 22. 

c) Da 22 zwischen 20 und 25 liegt, müssen die Personenstunden für den 
BFP von 22 (PS(22)) zwischen PS(20) = 18 und PS(25) = 22 liegen. 
Um den Wert PS(22) abzuschätzen, kann eine lineare Interpolation 
durchgeführt werden: 

PS(22) = PS(20) -k 2/5 • (PS(25) - PS(20)) = 18 -k 0,4 • 4 = 19,6 

4. a) i. Anlegen eines neuen Studierendendatensatzes: 

Funktionstyp: Dateneingabe 
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Komplexität: zumindest mittel aufgrund der Anzahl der un- 

terschiedlichen Datenelemente; bei Eingabeprü- 
fung, ob der/die Studierende schon in der Da- 
tenbank enthalten ist, sogar komplex. 

ii. Eingabe einer Klausur-/Prüfungsnote: 

Funktionstyp: Dateneingabe 

Komplexität: einfach, da lediglich Klausurnummer, Matrikel- 

nummer sowie die Note benötigt werden (d. h. 
weniger als sechs Datenelemente). 

iii. Druck-Ausgabe der Noten: 

Funktionstyp: Datenausgabe 

Komplexität: einfach, da Liste mit weniger als sieben Spalten. 

iv. Online-Abfrage der Adresse: 

Funktionstyp: Datenabfrage 

Komplexität: mittel, da zwei Schlüssel (nämlich Matrikelnum- 

mer in einer Tabelle mit den Angaben zu den 
Studierenden (Namen, Adresse usw.) und Ma- 
trikelnummer in einer Tabelle mit den Klausur- 
noten) . 

b) Als Summe der Schwierigkeitsgrade für die Anforderungen aus Teil- 
aufgabe a) ergibt sich Sl' = 6-|-3-|-4-|-4 = 17 und damit insgesamt 
S1 = 437 +n = 454. Hieraus folgt: BFP = 454 • 1,05 = 476,7, 
wodurch sich ein Aufwand von 31 PM abschätzen lässt. 



B.7 Betriebliche Anwendungssysteme (zu Abschnitt 7.7) 

1. Standardsoftware hat gegenüber Individualsoftware u. a. den Vorteil, dass 
die Einführungsdauer des Systems in der Regel kürzer und das System 
dadurch schneller verfügbar ist. Des Weiteren sind die (Anschaffungs-) 
Kosten für Standardsoftware zumeist geringer. Diese beiden Überlegun- 
gen können beim Einkauf eines Simulationssystems eine große Bedeutung 
besitzen. 

Standardsoftwaresysteme für die Simulation beinhalten in der Regel 
vordefinierte Komponenten und sind möglicherweise objektorientiert 
gestaltet. Dadurch wird eine Anpassung der Komponenten an den zu 
simulierenden Wirklichkeitsausschnitt ermöglicht. Somit sind derartige 
Simulationssysteme relativ flexibel hinsichtlich ihrer Anwendungsgebie- 
te, so dass im Allgemeinen (aus Anwendersicht) keine Notwendigkeit zur 
Entwicklung einer Individualsoftware besteht. 



2. • Zugangssysteme: 
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— Kunde verschafft sich Zugang zum Anwendungssystem, z. B. Aufbau 
einer Verbindung vom PC zum Anwendungssystem oder Zugang zu 
Selbstbedienungsterminals 

— wichtig: Prüfung der Authentizität des Kunden (u. a. durch Kenn- 
nummern, Passwörter, Chipkarten) 

— Anwendung im Busreiseunternehmen z.B. bei Reisebuchung oder 
Informationen über bereits gebuchte Reisen per Internet (Zugang 
zum entsprechenden Server des Busreiseunternehmens nötig, bei 
bereits gebuchter Reise auch Authentifizierung, ebenso bei einer 
Buchung) 

Informations- und Beratungssysteme: 

— hoher Erklärungsbedarf zum Produkt wegen Immaterialität und In- 
dividualität 

— Informationssysteme (Abruf von Angebots- und Leistungsdaten) 

— Beratungssysteme (durch Experten- oder Expertisesysteme) 

— Anwendung im Busreiseunternehmen z.B. bei einem Informations- 
angebot über das Internet (Informationen zu den Reisen und den 
Bedingungen), also eher in Form von Informationssystemen 

Transaktionssysteme: 

— Abwicklung von formalisierten und meist kurzen Verarbeitungs- 
vorgängen im Dialog, wobei sich nur Eingabeparameter ändern (z. B. 
P latzreservierung) 

— sowohl im Front-Office-Bereich für den Kunden, als auch im Back- 
Office-Bereich für den Sachbearbeiter 

— Anwendung im Busreiseunternehmen z. B. bei Reisebuchung per 
Internet oder auch im Reisebüro (dann die Software betreffend, mit 
der der Kundenberater dort arbeitet) 

Integrierte Bürosysteme: 

— Standardsoftware (z. B. Textverarbeitung, Tabellenkalkulation, 
Desktop-Publishing, Datenbankverwaltung) 

— „integrierte“ Arbeitsumgebung am Schreibtisch (Geräteintegration, 
Medienintegration, Funktionsintegration) 

— Anwendung im Busreiseunternehmen z.B. Textverarbeitung für 
den Schriftverkehr und Datenbankverwaltung der Reiseangebote, 
-buchungen und Kundendaten 

Administrations-, Dispositions-, Planungs- und Kontrollsysteme: 

— in allen Funktionsbereichen aller Branchen vorhanden 

— dazu gehören u. a. Anwendungen für das Berichtswesen, Ver- 
waltungsfunktionen, Anwendungen für die Vertriebsunterstützung, 
Management-Support-Systeme sowie Yield-Management-Systeme 

— Anwendung im Busreiseunternehmen z. B. für das Controlling 
(Auswertung der Reiseangebote und deren Akzeptanz) 
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• Workflow-Management-Systeme: 

— Vorgänge werden in Büroumgebung mit Arbeitsteilung abgewickelt 

— Vorgangsabwicklung erfolgt durch teilweise sequenzielle, teilweise 
parallele Ausführung von Vorgangsschritten 

— Anwendung im Busreiseunternehmen z.B. bei der Abwicklung 
einer Reisebuchung (Buchung der Reise durch einen Mitarbeiter, 
Weiterleitung an einen zweiten Mitarbeiter zur Rechnungslegung) 

• Workgroup-Computing-Systeme: 

— Computer gestützte Konzepte, Methoden und Realisierungen zur Un- 
terstützung von Teams bei Bearbeitung einer gemeinsamen unstruk- 
turierten Aufgabe 

— computergestützte Kooperation basiert auf Netzwerkarchitekturen 
mit Kommunikationssystemen 

— Anwendung im Busreiseunternehmen eventuell bei Gruppenent- 
scheidungen über neu aufzunehmende Reiseangebote, bei kleinem 
Unternehmen aber kaum nötig 

• Dokumentenmanagementsysteme: 

— zur Speicherung, Verwaltung und Wiedergewinnung von Dokumen- 
ten in elektronischer Form 

— Anwendung im Busreiseunternehmen z.B. bei der Verwaltung des 
per PC abgewickelten Schriftverkehrs (insbesondere bei Reklama- 
tionen und anderem nicht standardisiertem Schriftverkehr) 

3. Entschlüsselung von 11 mittels eigenem Secret Key: 11® mod 21 = 
161051 mod 21 = 2. (Dies kann man leicht mit einfacher Schulmathe- 
matik ausrechnen.) 2 ist eine Primzahl; d. h., an Bob muss folglich die 
Information 2 übermittelt werden. Verschlüsseln von 2 mit Bobs Public 
Key: 2^ mod 65 = 128 mod 65 = 63. Das heißt, an Bob muss die Nach- 
richt 63 geschickt werden. 
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239 

Customizing, 38, 101, 102, 208, 214 

Darstellungsschicht, 46 
Data Dictionary, 155, 174 
Data Encryption Standard, 223 
Data Mining, 79 
Data Warehouse, 172 
Daten, 23, 66, 94 

- operative, 172 

Datenübertragung, verbindungslose, 47 
Datenabfrage, 168 
Datenbank, 153 

- formatierte, 174 

- relationale, 156 
Datenbankabfrage, 168 

- Optimierung, 171 
Datenbankanwendung, 34 
Datenbankarchitekturmodell, 154 
Datenbankmanagementsystem, 153 



Datenbankstruktur, 158 
Datenbanksystem, 153 
Datenbestand, unformatierter, 174 
Datendefinition, 165 
Datenflussdiagramm, 120 
Datenintegration, 97, 212 
Datenintegrität, 97, 219 
Datenkatalog, 174 
Datenmanagement, 83, 173 
Datenmanipulation, 167 
Datenmodell, 105 

- relationales, 156 
Datenmodellierung, 94, 105 
Datenschutz, 84, 264 
Datenschutzrecht, 266 
Datensicherheit, 84 
Datensicht, 94, 100, 105 
Datenstruktur, 105 
Datentyp, abstrakter, 130 
Datenunabhängigkeit 

- logische, 155 

- physische, 155 
Decision Support System, 82 
Definition, 180 

Design, 180 

- objektorientiertes, 130 
Design Pattern, 198 
Dezimalsystem, 24 
Dienst, 39, 43-45, 47 
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Dienstleistungsunternehmen, 4 
Diskret isierung, 25 
Dispositionssystem, 4, 209, 210 
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Dokument, 216 

Dokumentenmanagement, 77, 216 
Dokumentenmanagementsystem, 216 
Domain, 106, 199 
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Domänenentwurf, 201 
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Electronic Data Interchange, 250 
Electronic Procurement, 248, 252 
Elektronische Datenverarbeitung, 255 
Enterprise Resource Planning, 207 
Entität, 106 
Entity, 106 

Entity-Relationship-Modell, 106 
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Entscheidung, 65 

Entscheidungsbaum, 119 

Entscheidungstabelle, 119 

Entscheidungsunterstützungssystem, 82 

Entwurf, 180 

Entwurfsmuster, 198 

Ereignisgesteuerten Prozessketten, 122 

Ereigniskalender, 136 
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Extensible Markup Language, 53, 252 
Extensible Stylesheet Language, 56 
Extensible Stylesheet Language for 
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Führungssystem, 209 
Fachkonzept, 96, 100 
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Feature-Diagramm, 200 
Feinentwurf, 180 
Fertigstellungsgrad, 192 
Festplatte, 29 
Firewall, 221 
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Front Office, 215 
Function-Point-Methode, 193 
Funktion, 95, 117 
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Funktionshierarchiediagramm, 118 
Funktionsmodellierung, 95, 117 
Funktionssicht, 95, 100, 117 
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Hexadezimalsystem, 24 
Home-Banking, 249 
Host, 40 

Hypertext, 51, 52 

Hypertext Markup Language, 52 
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- objektorientierte, 130 
Implementierungsebene, 96, 100 
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Individualsoftware, 37, 213 
Informatik, 13 

Information, 13, 23-25, 67-69 

- Asymmetrie, 66 

- nutzenorientierter Informationsbe- 
griff, 67 

Information Hiding, 130 
Information Highway, 38, 39 
Information Retrieval, 175 
Information Systems, 1 
Informations- und Kommunikationssys- 
tem, 1, 3 

Informationsallokation, 73 
Informationsbedarf, 74 

- nachgefragter, 74 

- objektiver, 74 

- subjektiver, 74 
Informationsbereitstellung, 73 
Informationsbeschaffung, 76 
Informationsdistribution, 73, 74 
Informationseinheit, 23 
Informationseinsatz, 73 
Informationsfunktion, 65 
Informationsinfrastruktur, 65 
Informationslogistik, 5, 73, 237 
Informationsmanagement, 7, 63-72 

- persönliches, 279 

- Ebenenmodell, 69 

- externes, 70 
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Informationsnachfrage, 74 
Informationsobjekt, 94 
Informationsparadoxon, 68 
Informationsplanung, 73 
Informationsproliferation, 75 
Informationssicht, 94 
Informationsstand, 74 
Informationssystem, 1-3 
Informationstechnologie-Infrastruktur, 

83 

Informationsverarbeitung, 255 
Instanz, 106 

Institute for Operations Research and 
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Integration, 181, 207, 211 

- horizontale, 211 

- vertikale, 211 
Interaktionsdiagramm, 134 
Intermediär, 252 
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Internet, 8, 39 
Interpreter, 37 
Intranet, 8, 41 
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IP-Adresse, 48 
IS-A-Beziehung, 111 
ISO-Referenzmodell, 45 
ISO/OSI-Modell, 45 
Isolation, 156 

Join, 157, 169 

Kapazitätsplanung, 191 
Kardinalität, 108 
Kartesisches Produkt, 157 
Katastrophenmanagement, 84 
Kette, logistische, 234 
Kilobyte, 24 
Kiosksystem, 238 
Klasse, 105, 106, 129 

- abstrakte, 198 
Klassen, 129 

Klassendiagramm, 131, 132 
Klassifikation, 105 
Kollaborationsdiagramm, 134 
Kölner Integrationsmodell, 102 
Kommunikation, 3 
Kommunikationsinfrastruktur, 39 
Kommunikationsprotokoll, 39 
Kommunikationssystem, 1-3 
Kompatibilität, 183 



Komplexität 

- asymptotische Laufzeitkomplexität, 
17 

- eines Beziehungstyps, 109 

- 0-Notation, 17 
Komplexitätstheorie, 17 
Komponente, 196 
Komponentendiagramm, 133 
Komponententechnik, 196, 202 
Kondratieff-Zyklus, 266 
Konfigurierung, 214 
Konsistenz, 155 
Kontrollierter Zugang, 219 
Kontrollsystem, 209, 210 
Koordinationsform, 87 
Kopplung 

- datenorientierte, 211 

- ereignisorientierte, 211 

- nachrichtenorientierte, 211 
Kostenplanung, 191 
Kryptoanalyse, 221 
Kryptographie, 221 
Kürzeste- Wege-Problem, 20 

Lastenheft, 179 
Laufzeitkomplexität, 17 

- exakte, 20 
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- konstante, 18 
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Lebenszyklus, 178 
Leistungssicht, 100 
Leitstand, 232 
Leitungsvermittlung, 50 
Lernen, 67 
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Linux, 32 
Lösbarkeit 

- effiziente, 20, 22 
Lösung, 22 
Lotus Notes, 218 

M-Commerce, 248 
Magnetplatte, 29 
Management-Support-System, 82 
Mantisse, 25 

Markt, elektronischer, 252 
Maschinensprache, 32 
Mediation, 268 
Megabyte, 24 
Meilenstein, 184 

Mensch-Maschine-Schnittstelle, 29 
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Merkmalsdiagramm, 200 
Metaheuristik, 22 
Metamodell, 93 
Metrik, 193 
Microsoft Windows, 32 
Middleware, 202 
Mobilkommunikation, 43 
Model Driven Architecture, 197 
Modell, 91 

- mathematisches, 119, 140 
Modellierung, 91 

- datenorientierte, 94, 105 

- funktionsorientierte, 95, 117 

- objektorientierte, 96, 129 

- organisationsorientierte, 115 

- prozessorientierte, 95 
Modellierungsprinzipien, 102 
Modul, 180 

Modularisierung, 88, 211 
Multitasking, 31 
Multithreading, 31 
Muster, 198 

Netzplantechnik, 191 
Netzwerkmanagement, 83 
Normalform, 158-160 
Normalisierung, 158 
MV, 21 
AfP-schwer, 22 

O-Notation, 17 
Objekt, 106, 129 
Objektdiagramm, 133 
Objektorientierung, 129 
Objekttyp, 105, 106 
Office-Paket, 38, 214 
Oktalsystem, 24 

Online Analytical Processing, 172 
Online Transaction Processing, 172 
Operatives System, 209 
Optimierungsmodell, 94, 141 
Optimierungsproblem, lineares, 141 
Organigramme, 115 
Organisationseinheit, 115 
Organisationsfluss, 99 
Organisationsmodellierung, 95, 115 
Organisationssicht, 94, 95, 100, 115 
Outsourcing, 87, 213 

V, 20 
Paging, 28 

Parametrisierung, 214 
Parser, 54 
Peripherie, 29 



Peripheriegerät, 29 
Persistenz, 156 
Personal Computer, 27 
Personenmonat, 193 
Pervasive Computing, 266 
Pervasive Innovation, 266 
Petabyte, 24 
Petri-Netze, 125 
Pflege, 182 
Pflichtenheft, 180 
Phase, 178 

Physikalische Schicht, 45 
Pilotsystem, 188 
Planung, 179 
Planungssystem, 209, 210 
Port-Nummer, 47 
Portabilität, 183 
Präsentationssystem, 215 
Primärschlüssel, 106 
Primärspeicher, 28 
Produktionsplanungs- und 
-Steuerungssystem, 230 
Programmablaufplan, 119 
Programmiersprache, 32 

- deduktive, 35 

- deklarative, 34, 35 

- deskriptive, 34 

- objektorientierte, 36 

- prozedurale, 33 
Programmierung, 32 

- objektorientierte, 130 

- strukturierte, 33 
Projekt, 190 

Projektablaufplanung, 191 
Projektbudgetierung, 192 
Projektcontrolling, 192 
Projektion, 157, 168 
Projektmanagement, 190 
Projektplanung, 191 
Projektstrukturplan, 191 
Protokoll, 39, 44 
Prototyp, 188 
Prototyping, 188 
Prozess, 31, 95, 117 

Prozessketten, Ereignisgesteuerte, siehe 
Ereignisgesteuerte Prozessketten 
Prozessmodell, 184 
Prozessmodellierung, 95 
Prozessor, 27 

- Rechenwerk, 27 

- Register, 28 

- Steuerwerk, 27 
Prozesssicht, 95, 117 
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Pull-System, 218 
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Qualitätsfaktor, 183 
Qualitätsmerkmal, 183 
Qualitätssicherung, 182 
Querschnittssystem, 210 
Query, 168 

Radio Frequency Identification, 30 
Realisierungskontrolle, 192 
Realwissenschaft, 2 
Rechenwerk, 27 

Rechner- und Installationsmanagement, 
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Rechnerarchitektur, 26 

- Von-Neumann- Architektur, 26 
Rechnername, 49 
Rechnersystem, 26 
Redundanzarmut, 174 
Referenzmodell, 101 
Register, 28 

Relation, 156 
Relationenalgebra, 156 
Relationship, 106 
Release, 182 
Replikation, 218 
Repository, 58 
Ressourcenfluss, 99 
Restschätzung, 192 
Revenue Management, 239 
RISC-Prozessor, 28 
Robustheit, 183 
Rolle, 115 

Rundreiseproblem, 20 

Sammlung, 105 
Schema, 154 
Schichtenmodell, 44 
Schlüssel, 106 
Schlüsselattribut, 157 
Sekundärspeicher, 29 
Selektion, 157, 168 
Sequenzdiagramm, 134 
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Sicherheit, 218 

- Anforderungen, 218 

- Bedrohungen, 219 

- Mechanismen, 220 
Sicherheitsmanagement, 84 
Sicherungsschicht, 46 
Sicht, 92, 94, 154, 171 
Simulation, 93, 135 
Simulationsmodell, 93 



Simulationssystem, 136 
Simulator, 136 
Sitzungsschicht, 46 
Software, 30 

- Anpassbar keit, 183 
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- Erweiterbar keit, 183 

- Kompatibilität, 183 

- Portabilität, 183 

- Release, 182 

- Robustheit, 183 

- Version, 182 

- Wiederverwendbarkeit, 183 
Software Engineering, 177 
Softwarequalität, 182 
Softwarearchitektur ,211 
Softwareentwicklung, 177 

- Aktivität, 177, 179 

- inkrementell-iterative, 189 

- Phase, 178 

- Wiederverwendung, 196 
Softwarekomponenten, 196 
Softwarelebenszyklus, 178 
Softwaretechnik, 177, 178 

- objektorientierte, 196 
Softwarewerkzeug, 37 
Softwarewiederverwendung, 196 
Speicher 

- Cache, 28 

- externer, 29 
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- optische Medien, 29 

- RAM, 28 

- ROM, 28 

- virtueller, 28 
Speichervermittlung, 50 
Speicherverwaltung 
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Spezialisierung, 105, 111, 131 

- disjunkte, 112 
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SQL, 35, siehe Structured Query 
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Standardsoftware, 37, 213 
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Steiner-Problem in Graphen, 21 
Stelle, 115 
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Stellen- Transitions-Netz, 126 
Steuerungssicht, 100 
Steuerwerk, 27 

Structured Query Language, 164 
Struktogramm, 119 
Strukturierte Analyse, 121 
Strukturierte Programmierung, 33 
Strukturplanung, 191 
Stylesheet, 56 

Supply Chain Management, 228, 234 
System, 3 

- operatives, 209 
Systemanalyse, 7 
Systemlebenszyklus, 80 
Systemsoftware, 30 

Tabelle, 156 
TCP/IP, 40, 47 
Telnet, 39 
Terabyte, 24 
Test, 181 

Top Level Domain, 49 
Tracing, 244 
Tracking, 244 
Transaktion, 155 

Transaktionsdatenverarbeitung, 172 
Transaktionskosten, 66 
Transaktionssystem, 172, 215 
Transitionen, 125 
Transponder, 30 
Transportproblem, 141 
Transportschicht, 46 
Traveling-Salesman-Problem, siehe 
Rundreiseproblem 
Turing-berechenbar, 15 
Typisierung, 105 

Übertragungskapazität, 41 
Ubiquitous Computing, 266 
Unified Modeling Language, 101, 106, 
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Uniform Resource Identifier, 52 
Uniform Resource Locator, 52 
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Integration, 58 
Universalrelation, 158 
Unix, 32 

Unternehmensdatenmodell, 7, 102 
Unternehmensmodellierung, 91, 94 

- Sichten, 94 

V-Modell, 186 
V-Vorgehensmodell, 186 
Validation, 182, 186 



Validierung, 182, 186 
Vendor Managed Inventory, 236 
Verallgemeinerung, 105 
Vererbung, 131 
Verfügbarkeit, 219 
Verfahren, effizientes, 20 
Verifikation, 181, 186 
Vermittlungsschicht, 46 
Verteilungsdiagramm, 133 
Vertraulichkeit, 218 
View, 154, 171 
Virtualisierung, 31 
Vollautomation, 14, 212 
Von-Neumann-Architektur, 26 
Vorgangskettendiagramm, 98 
Vorgehensmodell, 177, 184 

- inkrementell-iteratives, 189 

- Prototyping, 188 

- V-Modell, 186 

- Wasserfallmodell, 185 

Warenwirtschaftssystem, 252 

Wartung, 182 

Wasserfallmodell, 185 

Web Service, 57, 211 

Web Services Description Language, 59 
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WHILE-Programmiersprache, 15 
Wiederverwendbarkeit, 183 
Wiederverwendung, 196 
Wirtschaftsinformatik, 1, 9, 255 
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- Langfristziel, 14 
Wissen, 67, 77 

- explizites, 77 

- implizites, 77 
Wissensbasiertes System, 82 
Wissenschaft, 256 
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Wirtschaftsinformatik, 259 
Wissenschaftstheorie, 256 
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- Bausteine, 77 
Workflow Management, 218 
Workflow-Management-System, 115, 
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Yield Management, 239 
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Zeichenmenge, 23 
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Zustandsdiagramm, 133 
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